私が遭遇したのは、バグだと思っていたものが、実際にはこの投稿で詳しく説明されている機能です。これが許可されている理由を誰かに説明してもらえますか? 便利になったレガシーの癖/バグのようです。
2 に答える
どの部分がバグだと思うかはわかりませんが、コンパイル時にアクセスできない場合でも、リフレクションを介してクラスの内部にアクセスすることは常に可能でした。これは仕様によるものです。CLR の多くの側面は、シリアル化などのフィールドにアクセスするためにリフレクションに依存しています。コンパイルされた IL は、すべてのオブジェクトのすべてのフィールドにアクセスできる必要があります。そうしないと、クラス内からプライベート フィールドを設定できませんでした。
C# のアクセス修飾子はセキュリティ メカニズムではありません。誰かが外部からフィールドを設定できないようにするために、フィールドがプライベートであることに依存している場合は、何か間違ったことをしています。これらは、クラスのどの部分がパブリック コントラクトであるか (したがって、理論的には安定している)、実装の詳細である部分 (したがって、予告なしに変更される可能性があります) を明確に区別するために存在します。
リフレクションを使用してオブジェクトの内部状態を変更することを選択した場合、そのままにしておく必要があるというすべての兆候にもかかわらず、アプリケーションの安定性を自分の手に委ねることになり、それに値するものを手に入れることができます。
リフレクションは完全信頼コードに対してのみ許可されているため、コードはすでに何でも実行できます (プロセスのメモリを直接突くなど)。したがって、プライベート プロパティの値を変更する方法をサポートしても、コードの安全性が低下することはありません。これにより、リフレクション API の一貫性が保たれ、特にテストに役立つシナリオが可能になります。