パブリックフィールドと自動プロパティ

フィールドを外部に公開するのではなく、クラスフィールドのゲッターメソッドとセッターメソッド（C＃のプロパティ）を作成してカプセル化を保護する必要があるとよく言われます。

しかし、フィールドが値を保持するためだけに存在し、取得または設定するための計算を必要としない場合がよくあります。これらについては、私たちはすべてこの数を行います：

public class Book
{
    private string _title;

    public string Title
    {
          get{ return _title;  }
          set{ _title = value; }
    }
}

まあ、私は自白があります。私はそれをすべて書くことに耐えられなかったので（本当に、それを書く必要はなく、それを見る必要がありました）、私は不正に行き、パブリックフィールドを使用しました。

その後、C＃3.0が追加され、自動プロパティが追加されたことがわかります。

public class Book
{
    public string Title {get; set;} 
}

どちらかと言うと整然としていますが、私は感謝していますが、実際には、パブリックフィールドを作成することと何が違うのでしょうか。

public class Book
{
    public string Title;
}

少し前にあった関連する質問で、いくつかの違いを説明するジェフのブログへの投稿へのリンクがありました。

プロパティとパブリック変数

• リフレクションは変数とプロパティでは動作が異なるため、リフレクションに依存している場合は、すべてのプロパティを使用する方が簡単です。
• 変数に対してデータバインドすることはできません。

• 変数をプロパティに変更すると、重大な変更になります。例えば：

  TryGetTitle(out book.Title); // requires a variable

APIの問題を無視すると、プロパティの使用に関して最も価値があると思うのはデバッグです。

CLRデバッガーはデータブレークポイントをサポートしていません（ほとんどのネイティブデバッガーはサポートしています）。したがって、クラスの特定のフィールドの読み取りまたは書き込みにブレークポイントを設定することはできません。これは、特定のデバッグシナリオでは非常に制限されています。

プロパティは非常に薄いメソッドとして実装されるため、値の読み取りと書き込みにブレークポイントを設定することが可能です。これは彼らにフィールドの上に大きな足を与えます。

フィールドからプロパティに変更すると、契約が破られます（たとえば、すべての参照コードを再コンパイルする必要があります）。したがって、他のクラス（パブリック（および一般に保護された）メンバー）との相互作用ポイントがある場合、将来の成長を計画する必要があります。常にプロパティを使用してください。

今日それを自動プロパティにするのは何の意味もありません。3か月後には、それを遅延ロードにしたいことに気づき、ゲッターにnullチェックを入れます。フィールドを使用していた場合、これは再コンパイルの変更であり、アセンブリに依存している人やものに応じて、最悪の場合は不可能です。

誰もそれを言及しなかったからといって、インターフェースでフィールドを定義することはできません。したがって、プロパティを定義する特定のインターフェイスを実装する必要がある場合、自動プロパティは非常に優れた機能になることがあります。

見過ごされがちで、他の回答では言及されていない大きな違い：オーバーライド。プロパティを仮想宣言してオーバーライドすることができますが、パブリックメンバーフィールドに対して同じことはできません。

バージョン管理とAPIの安定性がすべてです。バージョン1でも違いはありませんが、バージョン2でこれを何らかのタイプのエラーチェックを備えたプロパティにする必要があると判断した場合、APIを変更する必要はありません。プロパティの定義。

パブリックフィールドに対する自動実装プロパティのもう1つの利点は、セットアクセサーをプライベートまたは保護にして、パブリックフィールドのコントロールよりも優れたコントロールが定義されたオブジェクトのクラスを提供できることです。

フィールドを作ることに問題はありませんpublic。ただしgetter/setter、privateフィールドでの作成はカプセル化ではないことを覚えておいてください。IMO、の他の機能を気にしない場合は、Property作成することもできますpublic。

後でタイトルが一意であることを確認する場合は、コレクションまたはデータベースと比較することにより、それに依存するコードを変更せずにプロパティで行うことができます。

パブリック属性だけを使用すると、柔軟性が低下します。

コントラクトを壊さない追加の柔軟性は、プロパティの使用に関して私にとって最も重要なものであり、実際に柔軟性が必要になるまで、自動生成が最も理にかなっています。

すべてのコードとテストの理由と同様に、私が非常に役立つと思うことの1つは、それがプロパティ対フィールドの場合、Visual Studio IDEはフィールドではなくプロパティの参照を表示するということです。

私のハメ撮りはいくつかの研究をした後

1. 検証。
2. アクセサーをオーバーライドして、プロパティの動作を変更できるようにします。
3. デバッグ目的。アクセサーにブレークポイントを設定することで、いつ、何がプロパティが変化するかを知ることができます。
4. フィールドはセットのみにすることができます。たとえば、public set（）およびprivate get（）。これはpublicフィールドでは不可能です。

それは本当に私たちにより多くの可能性と拡張性を与えます。