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




get set static (7)

フィールドを外部に公開するのではなく、クラスフィールドのgetterメソッドとsetterメソッド(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;
}

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

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

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


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


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


フィールドからプロパティへの変更は、契約を破ります(例えば、すべての参照コードを再コンパイルする必要があります)。 したがって、他のクラス(一般に保護されているメンバー)とのやりとりポイントを持つ場合、将来の成長を計画したいと考えています。 常にプロパティを使用してください。

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


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


私がしばらく前に持っていた関連する質問では、Jeffのブログにいくつかの違いを説明したポストへのリンクがありました。

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

  • リフレクションは、変数とプロパティで異なる働きをします。したがって、リフレクションに頼る場合、すべてのプロパティを使用する方が簡単です。
  • 変数に対してデータバインドすることはできません。
  • 変数をプロパティに変更することは大きな変更です。 例えば:

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

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





automatic-properties