リフレクションはプライベート変数を制限できないので不利ですか？

private修飾子は、クラス外部からのアクセスを制限するために使用されていますが、反射他のクラスを使用すると、プライベートメソッドとフィールドにアクセスすることができます。ですから、もしそれが要件の一部であるなら、どうやってアクセシビリティを制限できるのだろうと思っています。

アクセス修飾子の目的は、クラスのパブリックインターフェイスとは何かについてコードを記述する開発者に通知することです。これらは決してセキュリティ対策ではなく、文字通り情報を隠したり保護したりしません。

引用する クラスアクセス権についてハーブサッター：

「ここでの問題は、Murphyに対する保護とMachiavelliに対する保護です。つまり、偶発的な誤用（この言語は非常にうまくいきます）に対する保護です。プログラマーはシステムを破壊するほどひどく欲しがり、方法を見つけるでしょう」

いいえ、これは実際に重要な利点です。一部の開発者は、だれかが内部状態の一部にアクセスする必要があるとは考えなかったからといって、正当なユースケースが出現しないという意味ではありません。これらの場合、Reflectionを使用してオブジェクトの手術を行うことは最後の手段です。この手法を複数回使用する必要がありました。

実行環境というもう1つのレベルを上げることで、アクセシビリティをさらに制限できます。

すべての言語にこの概念があるわけではありませんが、少なくともJavaでは、プライベートフィールドへのアクセスを禁止するセキュリティマネージャーを使用できます。実行時にセキュリティマネージャを手動でインストールするか、jarファイルにセキュリティポリシーを追加して、変更を防ぐためにシールします。

Javaでこれを行うための詳細：Reflection Security

あなたはどんな反射について話しているのですか？

多くのリフレクションシステムでは、カプセル化の回避は、コードが取得する必要がある明示的な機能であり、デフォルトではありません。

カプセル化について懸念がある場合、単純な解決策は、それを保持しないリフレクションシステムを使用しないことです。

Pythonには、アクセス修飾子はありません。慣習では、クラスの外部からアクセスされることが予想されないメソッドと変数の前にアンダースコアを付けます。サードパーティクラスからそのようなフィールドにアクセスすることを技術的に妨げていますか？どういたしまして; しかし、もしそうなら、あなたは自分自身であり、他のクラスを責めることなく、何かを壊す危険を冒します。

C＃には、アクセス修飾子が存在しますが、それらはまだ慣習にすぎません。コンパイラによって強制されるものですが、慣習です。つまり、技術的には、Reflectionを使用するか、メモリを直接改ざんすることで（ゲームトレーナーのように）、プライベート変数にアクセスして変更することができます。ように）。結果はまったく同じです。クラスの変数が別のクラスからのリフレクションまたは別のアプリケーションによるメモリ改ざんによって変更され、それがクラス内の何かを壊す場合、それはあなたのせいではありません。

これにより、サードパーティがデータにアクセスできるセキュリティ問題が明らかに発生することに注意してください。文字列や類似のデータ構造の暗号化されたバリアントにつながる何か。しかし、そのような使用からコードを保護することは、より関連するOSとコードレベルのアクセス制限であり、Reflection自体とは関係ありません。