他の誰かが人々がこれを行うのを見たことがありますか:
private string _name;
public string Name{ get{ return _name; } set{ _name = value;}}
アクセサーの設定方法を制御したり、get があるときに何らかの機能を実行したりする場合は、アクセサーを使用することを理解しています。しかし、これを行うだけなら、最初から変数をパブリックにしてみませんか? 何か不足していますか?
メンバーをパブリック フィールドにすると、後でクラスへのインターフェイスを変更せずにプロパティにリファクタリングすることはできません。最初からプロパティとして公開すると、プロパティ アクセサー関数に必要な変更を加えることができ、クラスのインターフェイスは変更されません。
C# 3.0 以降では、バッキング フィールドを作成せずにプロパティを実装できることに注意してください。
public string Name { get; set; }
これにより、そもそも public フィールドをプロパティとして実装しない唯一の正当な理由が取り除かれます。
アセンブリ A でプロパティを使用してパブリック インターフェイスを定義すると、アセンブリ B でこのインターフェイスを使用できます。
これで、プロパティの実装を変更できます (値をフィールドに格納するのではなく、データベースから取得するなど)。その後、アセンブリ A を再コンパイルして、古いアセンブリを置き換えることができます。インターフェイスが変更されていないため、アセンブリ B は正常に続行されます。
ただし、最初に public フィールドから始めて、これが適切ではないと判断し、実装を変更して、それをプロパティに変換する必要があると判断した場合、これは変更する必要があることを意味します。アセンブリ A のパブリック インターフェイス。そのインターフェイスのクライアント (アセンブリ B を含む) も、この新しいインターフェイスを使用できるように再コンパイルして置き換える必要があります。
したがって、最初はプロパティから始めたほうがよいでしょう。これにより、プロパティの実装がカプセル化され、アセンブリ A を使用してどのクライアント (アセンブリ B を含む) が既に世界に出ているかを心配することなく、将来それを自由に変更できるようになります。アセンブリ A を使用してインターフェイスを変更すると、すべてのクライアントが壊れてしまいます。それらがあなたの会社の別のチームまたは別の会社で使用されている場合、あなたのインターフェイスを変更してアセンブリを壊すと、彼らは不満を抱くでしょう!
.NETのDataBindingもパブリックフィールドの処理を拒否し、プロパティを要求することに注意してください。それが別の理由かもしれません。
アクセサーを使用すると、API を変更せずに基になる実装を変更できるという考え方です。たとえば、名前を設定するときに、テキスト ボックスや別の変数も更新する必要があると判断した場合、クライアント コードを変更する必要はありません。
良いプログラミングの練習。これは、OO 設計方法論に適合する非常に一般的なパターンです。public フィールドを公開することで、そのデータがどのように保存されているかの内部を公開します。代わりにパブリック プロパティを使用すると、パブリック インターフェイスを壊さずに、データを内部に格納する方法をより柔軟に変更できます。また、データがアクセスされたときに何が起こるか (遅延初期化、null チェックなど) をより詳細に制御できます。
変数は、クラスの実装の一部です。プロパティは、それへのインターフェイスをより論理的に表します。C# 3.0 では、自動的に実装されたプロパティにより、最初から簡単に行うことができます。
これについては、変数からプロパティに変更すると、バイナリ互換性だけでなくソース互換性も損なわれるさまざまな方法を含め、これに関するより多くの考えをトピック の記事に書きました。
準備。将来的に set アクセサーを削除したり、setter で追加の操作を実行したり、get のデータ ソースを変更したりする必要がいつ生じるかはわかりません。
パブリックにアクセス可能なメンバーは、通常、フィールドではなくメソッドにする必要があります。これは良い習慣であり、その実践は、オブジェクトのカプセル化された状態が常に制御下にあることを保証するのに役立ちます。
カプセル化のために、パブリック フィールドを使用することはお勧めしません。
http://my.safaribooksonline.com/9780321578815/ch05lev1sec5?displaygrbooks=0
Chris Anderson がこの本の後半で述べたように、呼び出し元がフィールドとプロパティの違いを認識していないことが理想的です。
すべてのアセンブリを再コンパイルする手間をかけずに高度な拡張性を維持するには、パブリック プロパティをアクセサーとして使用します。オブジェクトがどのようにデータを交換するかを説明する「コントラクト」または定義済みのメカニズムに従うことで、一連のルールが設定されます。このコントラクトはインターフェイスで強制され、このインターフェイスを継承するクラスのゲッターとセッターによって実行されます。
後でそのインターフェースから追加のクラスを作成する場合は、プロパティを使用して契約を順守する柔軟性がありますが、ゲッターとセッターを介してデータを提供しているため、データを組み立てる実装またはプロセスは、 「コントラクト」が期待するタイプを返すだけでなく、必要です。