この質問はばかげているように聞こえるかもしれませんが、パブリックのようなオブジェクトのフィールドを公開すると、他の人が悪用できるセキュリティ リスクやアプリケーションの穴が作成される可能性があることを知りたいという好奇心がありますか?
public class AClass
{
public int AProperty { get; set; }
//Less Secure?
public int APublicField;
}
ありがとう
アクセス修飾子 (public、private、protected) は、ソース アクセスを持つユーザーに対してさまざまなレベルのカプセル化を許可するメカニズムにすぎません。ロジックを保守しやすくするために、OOP のベスト プラクティスと共にそれらを採用する必要があります。アプリケーションのセキュリティとはまったく関係ありません。
C# では、RTTI を使用して、パブリック データと同じくらい簡単にプライベート データを反映できます。CLR と C# のバイナリ互換性が保証されているおかげで、独自の内部から外部バイナリでこれを実行することもできます。リフレクションを使用できなくても、攻撃者は逆アセンブラーを使用してコードを中間言語として検査できます。この投稿を読むことをお勧めします。
プラットフォームに精通している抜け目のない攻撃者は、 softICEなどのカーネル レベルのデバッガーを実行しているアプリケーションをリバース エンジニアリングする方法の手がかりを探すことさえできます。
実行を目立たなくするためにロジックをカプセル化することで、いつでも何らかの形のセキュリティを使用しようとすることができます。
セキュリティのための最善の策は、調査を行い、商用およびオープンソースの両方でよく使用されているライブラリを探すことです。ライブラリ開発者とホワイト ハットは、エクスプロイトが発見されたときに協力して修正できるため、暗号化が公開されるほど効果的です。
スニペットの 2 つの「フィールド」は本質的に同等です。最初のものは単純な自動プロパティです。したがって、どちらも多かれ少なかれ「安全」ではありません。
実際、セッターとゲッターは、OOP の歴史的なベスト プラクティスにすぎません。
公開したソリューションは両方とも、カプセル化を尊重しません。属性の名前またはタイプを変更すると、それが使用されているすべてのクラスで変更する必要があるためです。
ただし、public 属性の利点の 1 つは、取得するコードが少なくて済むことです。これにより、コードの理解と保守が容易になります。