クラス内のメンバー変数を使用する理由

Question

私はほとんどの人がクラスのメンバー変数を使用するのを見ました：

string _foo;
public string foo { get { return _foo; }; private set { _foo = value}; }

.

しかし、これとの違いは何ですか？

public string foo { get; private set; }

.

Answer 1

そのようなシンプルな場合は同じですが、あなたがイベントまたは何かを発射しているより複雑なケースで、あなたが取得と設定に追加のコードを必要とするより複雑なケースでは、メンバーex：

が必要です。

private string _name;
public string Name
{
   get{ return _name; }
   set
   {
      SomeHandler("Name", value);
      _name = value;
   }
}

.

Answer 2

物件の実装が実際に行われていないが取得および設定されていない限り、違いはかなり軽微です。それを使用する理由は次のとおりです。

• C＃3.0の前のレガシーコード（自動プロパティ、つまり。public string Name { get; set; }構文。
• getter / setterの実装をある時点で変更する必要があることを期待しています。
• カスタムシリアル化の要件
• コード内の基礎となるフィールドを使用してください。良い例は、基づいてrefパラメータとしてバッキングフィールドを使用している可能性があります。これには、ネイティブInterop（GCHandleなど）の値を使用するようなものも含まれます。
• 単純なユーザーの好み。私は通常自動プロパティを使用していません。私は手動でバッキングフィールドを指定するのが好きです。
• 自動プロパティを使用すると、readonlyバッキングフィールドを使用することはできません。

これは氷山の一角にすぎません。一連の厄介な理由もあり、誰かが反射を使ってそれにアクセスできるように、そのフィールドを明示的に宣言しなければならない。

Answer 3

「自動プロパティ」の導入前に、プロポーリーの「バッキングフィールド」を使用する必要があります。ほとんどの場合、プロポーリーは単に値を以下の例のように「バッキングフィールド」に設定します。

public string Name
{
   get { return _name; }
   set { _name=value; }
}

.

「自動プロパティ」の導入で、私たちは単に「バッキングフィールド」を無視することができます（または1つを供給する必要はありません）。あなたのデザインが上記の例のようなものであるならば、これはほとんど適していますが、値を取得しながらカスタムロジックの「種類」を強制する必要がある場合、または値を設定する前に、「古いデザイン」をたどる必要があります。バッキングフィールド）

Answer 4

さまざまなシナリオにはさまざまな利点があります。

string _FirsName;   
string _LastName;   

public string FullName 
{ 
   get 
   { 
      return _FirsName + _LastName;
   }
   set; 
} 

public string ReverseName 
{ 
   get 
   { 
      return _LastName + ", " + _FirsName;
   }
   set; 
}

.