c# - C# 3.0 の自動プロパティ — 役に立つかどうか?

Question

注: これは、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 行のコードを保存する以外に、これらの自動プロパティを使用する理由はありますか? 私の個人的な不満は、これらのプロパティが私から隠していることであり、私は黒魔術の大ファンではありません.

実際、非表示のプライベートフィールドはデバッガーにも表示されません。しかし、実際に getter/setter ロジックを実装したい場合は、プライベート/パブリックペアを使用する必要があります。

後で getter/setter ロジックを変更する機能を失うことなく、多くのコード (1 行対 6 行) を節約できるという利点がありますが、パブリックフィールド "Public string Title" を宣言せずに宣言するだけで、既にそれを行うことができます。 { get; の必要性設定; } ブロックすることで、より多くのコードを節約できます。

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

score 121 · Accepted Answer

Stack Overflow では常にそれらを使用しています。

Properties と Public Variablesの議論にも興味があるかもしれません。私見は、これが実際に反応しているものであり、その目的のために、それは素晴らしいことです.

score 64 · Accepted Answer

はい、コードを保存するだけです。それらがたくさんあると、読みやすくなります。それらはより速く書くことができ、維持するのがより簡単です。コードを保存することは常に良い目標です。

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

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"; }

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

score 46 · Accepted Answer

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

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

score 30 · Accepted Answer

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

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

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

score 29 · Accepted Answer

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

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

また、プロパティを使用すると、フィールドではできない getter と setter の異なるアクセスレベルを設定できます。

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

score 18 · Accepted Answer

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

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

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

getしたがって、これには単純/自動プロパティよりも優れた利点がありprivate setます。

score 12 · Accepted Answer

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

score 8 · Accepted Answer

自動プロパティは、C# の他の何よりも黒魔術です。最初に通常の C# プロパティに展開するのではなく、IL にコンパイルするという観点から考えると、他の多くの言語構造よりも黒魔術がはるかに少なくなります。

score 5 · Accepted Answer

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

私が見逃している唯一のことは、これを行うことができることです:

public string Name = "DefaultName";

プロパティを使用して、デフォルトをコンストラクターにシフトする必要があります。退屈な:-(

score 5 · Accepted Answer

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

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

Ruby はこれを最初から次のように行ってきました。

attr_accessor :my_property
attr_reader :my_getter
attr_writer :my_setter

score 2 · Accepted Answer

私が彼らと一緒に抱えている唯一の問題は、彼らが十分に進んでいないということです. 自動プロパティを追加したコンパイラの同じリリースでは、部分メソッドが追加されました。彼らが2つを一緒にしなかった理由は私を超えています. 単純な「部分的な On<PropertyName>Changed」だけで、これらの機能が非常に便利になります。

score 2 · Accepted Answer

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

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

score 1 · Accepted Answer

ここで注意すべきことの 1 つは、私の理解では、これはC# 3.0 側のシンタックスシュガーに過ぎないということです。つまり、コンパイラによって生成される IL は同じです。黒魔術を避けることについては同意しますが、それでも、同じことに対してより少ない行が通常は良いことです。

score 1 · Accepted Answer

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

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

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

これを行う：

フィールドの名前を変更する
非公開にする
パブリックプロパティを追加する

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

ただし、いつの日か、システムが拡大し、それを個別のアセンブリと複数のソリューションに分解することになります。その場合、Jeff が述べたように、パブリックフィールドをパブリックプロパティに変更することは API の重大な変更になるため、公開されたフィールドが戻ってきて悩まされます。

score 0 · Accepted Answer

自動プロパティに関する私の最大の不満は、それらが時間を節約するように設計されていることですが、後で本格的なプロパティに拡張しなければならないことがよくあります。

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

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

score 0 · Accepted Answer

自動プロパティよりも高速な CodeRush を使用しています。

これをする：

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

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

score 0 · Accepted Answer

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

public string Title { get; }

また

public string Title { get; private set; }

これはあなたが言及しているものですか？

score 0 · Accepted Answer

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

c# - C# 3.0 の自動プロパティ — 役に立つかどうか?

18 に答える 18

Related

Reference