C＃3.0自動プロパティ—有用かどうか？[閉まっている]

注：これは、C＃を使い始めたときに投稿されました。2014年の知識があれば、自動プロパティはC＃言語でこれまでに起こった中で最高のものの1つであると本当に言えます。

プライベートフィールドとパブリックフィールドを使用して、C＃でプロパティを作成するのに慣れています。

private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

今、.NET 3.0では、自動プロパティを取得しました。

public string Title { get; set; }

私はこれが哲学的/主観的な質問であることを知っていますが、各フィールドに5行のコードを保存する以外に、これらの自動プロパティを使用する理由はありますか？私の個人的な不満は、これらのプロパティが私から何かを隠していることであり、私は黒魔術の大ファンではありません。

実際、非表示のプライベートフィールドはデバッガにも表示されません。これは、get / set関数が何も実行しないという事実を考えると問題ありません。しかし、実際にゲッター/セッターロジックを実装する場合は、とにかくプライベート/パブリックペアを使用する必要があります。

後でゲッター/セッターのロジックを変更する機能を失うことなく、多くのコード（1行と6行）を保存できるというメリットがありますが、パブリックフィールド "Public string Title"を宣言せずに、すでにそれを行うことができます。 {getの必要性; セットする; }ブロックし、さらに多くのコードを保存します。

それで、ここで何が欠けていますか？なぜ誰もが実際に自動プロパティを使用したいのですか？

スタックオーバーフローでは常に使用します。

プロパティとパブリック変数の比較にも興味があるかもしれません。私見これは本当にこれに対する反応であり、そのためには素晴らしいことです。

はい、コードを保存するだけです。大量にあると読みやすくなります。記述が速く、保守も簡単です。コードを保存することは常に良い目標です。

さまざまなスコープを設定できます。

public string PropertyName { get; private set; }

そのため、プロパティはクラス内でのみ変更できます。リフレクションを介してプライベートセッターにアクセスできるため、これは実際には不変ではありません。

C＃6以降では、真のreadonlyプロパティ、つまりコンストラクターの外では変更できない不変のプロパティを作成することもできます。

public string PropertyName { get; }

public MyClass() { this.PropertyName = "whatever"; }

コンパイル時に次のようになります。

readonly string pName;
public string PropertyName { get { return this.pName; } }

public MyClass() { this.pName = "whatever"; }

多くのメンバーを持つ不変クラスでは、これにより余分なコードが大幅に節約されます。

プロパティの代わりにフィールドを使用することの3つの大きな欠点は次のとおりです。

1. フィールドにデータバインドすることはできませんが、プロパティにバインドすることはできます
2. フィールドの使用を開始した場合、後で（簡単に）プロパティに変更することはできません
3. フィールドに追加できないプロパティに追加できる属性がいくつかあります

私は個人的に自動プロパティが大好きです。コード行を保存することの何が問題になっていますか？ゲッターやセッターで何かをしたい場合は、後でそれらを通常のプロパティに変換しても問題はありません。

あなたが言ったように、あなたはフィールドを使うことができて、あなたが後でそれらにロジックを追加したいなら、あなたはそれらをプロパティに変換するでしょう。しかし、これはリフレクションの使用で問題を引き起こす可能性があります（そしておそらく他の場所で？）。

また、プロパティを使用すると、フィールドでは実行できないゲッターとセッターに異なるアクセスレベルを設定できます。

varキーワードと同じだと思います。個人的な好みの問題。

C ++の作成者であるBjarne Stroustrupから：

特に、get関数とset関数が多いクラスは嫌いです。多くの場合、それはそもそもクラスであってはならないことを示しています。これは単なるデータ構造です。そして、それが本当にデータ構造である場合、それをデータ構造にします。

そして、あなたは何を知っていますか？彼は正しい。単に「オブジェクト指向」であるため、実際にget / set内で何も行わずに、getおよびsetでプライベートフィールドを単にラップする頻度はどれくらいですか。これは問題に対するマイクロソフトのソリューションです。それらは基本的に、バインドできるパブリックフィールドです。

残念ながら、自動プロパティが不変オブジェクト（通常は不変構造体）に役立たないことは、誰も言及していないようです。そのため、あなたは本当にすべきです：

private readonly string title;
public string Title
{
    get { return this.title; }
}

（フィールドは渡されたパラメーターを介してコンストラクターで初期化され、その後読み取り専用になります。）

そのため、これには単純なget/ private set自動プロパティよりも利点があります。

インターフェース定義でプロパティを使用でき、インターフェース定義でパブリックフィールドを使用できないため、私は常にパブリックフィールドの代わりにプロパティを作成します。

自動プロパティは、C＃の他のものと同じくらい黒魔術です。最初に通常のC＃プロパティに展開するのではなく、ILにコンパイルするという点でそれについて考えると、他の多くの言語構成要素よりもずっと黒魔術が少なくなります。

私は常に自動プロパティを使用しています。C＃3以前は、すべての入力に煩わされることはなく、代わりにパブリック変数を使用していました。

私が見落としているのは、これを実行できることだけです。

public string Name = "DefaultName";

プロパティを持つコンストラクタにデフォルトをシフトする必要があります。面倒:-(

直感的で、コードの行を削減する構成は、大きなプラスになると思います。

これらの種類の機能は、Rubyのような言語を非常に強力にするものです（それは、余分なコードの削減にも役立つ動的機能です）。

Rubyはこれをずっと持っていました：

attr_accessor :my_property
attr_reader :my_getter
attr_writer :my_setter

私が彼らに持っている唯一の問題は、彼らが十分に遠くに行かないことです。自動プロパティを追加したコンパイラの同じリリース、部分メソッドが追加されました。彼らが2つをまとめなかった理由は私を超えています。単純な "部分的なOn <PropertyName> Changed"があれば、これらのことは本当に便利になります。

それはシンプルで短く、プロパティの本体内のどこかに実際の実装を作成したい場合でも、型の外部インターフェイスを壊すことはありません。

それと同じくらい簡単です。

ここで注意すべき点の1つは、私の理解では、これはC＃3.0側の単なる構文上の糖衣であり、コンパイラーによって生成されるILが同じであることを意味します。私は黒魔術を避けることに同意しますが、同じことに対して、同じように、少ない行は通常良いことです。

私の意見では、パブリックフィールドではなく、常に自動プロパティを使用する必要があります。とはいえ、ここに妥協点があります。

プロパティに使用する命名規則を使用して、内部フィールドから始めます。あなたが最初に

• アセンブリの外部からフィールドにアクセスする必要がある、または
• ゲッター/セッターにロジックをアタッチする必要がある

これを行う：

1. フィールドの名前を変更する
2. プライベートにする
3. パブリックプロパティを追加する

クライアントコードを変更する必要はありません。

しかし、いつかはシステムが成長し、個別のアセンブリと複数のソリューションに分解することになります。それが起こると、公開されたフィールドはすべてあなたを悩ませるようになります。ジェフが述べたように、パブリックフィールドをパブリックプロパティに変更することは、APIの重大な変更だからです。

私はCodeRushを使用していますが、自動プロパティよりも高速です。

これをする：

 private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

合計8回のキーストロークが必要です。

コードスニペットを使用すると、同じ名前の自動プロパティは合計7つのキーストロークになります;）

@Domenic：わかりません..これを自動プロパティで行うことはできませんか？：

public string Title { get; }

または

public string Title { get; private set; }

これはあなたが言っていることですか？

自動プロパティに関する私の最大の不満は、時間を節約するように設計されていることですが、後で完全なプロパティに拡張する必要があることがよくあります。

VS2008に欠けているのは、Explode Auto-Propertyリファクタリングです。

カプセル化フィールドリファクタリングがあるという事実により、パブリックフィールドを使用するだけで作業が速くなります。