2008-09-14 9 views
78

自動実装されたプロパティのバッキング変数にはどのようにしてアクセスできますか?私たちはこのような特性を宣言した過去には

public class MyClass 
{ 
    private int _age; 

    public int Age 
    { 
      get{ return _age; } 
      set{ _age = value; } 
    } 
} 

は、今、私たちが行うことができます:

public class MyClass 
{ 
    public int Age {get; set;} 
} 

私の質問は、私はこの表記法を使用して自動的に作成されたプライベート変数にアクセスする方法、ありますか?

私はむしろ、プライベート変数にアクセスし、パブリック・アクセッサーの「Age」にはアクセスしません。プライベート変数にアクセスするための既定の表記法はありますか?そうではありませんか?

+10

プライベートアクセス許可とパブリックアクセス許可の違いは何ですか?宣言クラスのロジックからでもパブリックアクセサにアクセスすることがベストプラクティスだと思います。アクセサーにロジックを追加する場合は、コードをすべて変更する必要はありません。 –

+0

@ spoon16ロジックをアクセサに追加し、その結果としてすべてのコードを変更する必要があるという例を教えてください。私はこの部分を本当に理解していませんでした。 – Ogen

答えて

2

これは、IDE機能ではなく、言語機能です。正直言って私はあなたのためにプライベート変数を追加するIDEを好むだろう。クラス内で独自の変数にアクセスするためにパブリックエントリポイントを内部的に使用する必要があることは少し奇妙であることに同意します。したがって、私はこの新機能を自分では使用しません。 <接頭辞

プライベートメンバ変数の注入で何が起こるか舞台裏
10

、> k__AutomaticallyGeneratedPropertyField C# 3.0 Automatic Properties explained

から#

直接そのプライベートメンバを使用することが可能かもしれないが、それは非常にハッキーで不必要です。

12

この構文は一般に「構文糖」と呼ばれ、コンパイラがその構文をとり、それを他のものに変換することを意味します。コンパイラは、このようなものなコード生成しますあなたの例では、:

[CompilerGenerated] 
private int <Age>k_BackingField; 

public int Age 
{ 
    [CompilerGenerated] 
    get 
    { 
     return this.<Age>k_BackingField; 
    } 
    [CompilerGenerated] 
    set 
    { 
     this.<Age>k_BackingField = value; 
    } 

はそれさえものすべてを知っているが、あなたはおそらく直接バッキングフィールドにアクセスすることができますが敗北のその種自動プロパティを使用する目的。おそらくここでは、C#コンパイラの将来のリリースでいつでも変更できる実装の詳細に依存しているからです。

23

自動プロパティの使用は、プロパティの取得/設定ロジックが不要であるため、プライベートバッキング変数が不必要であることを意味します。

クラスに複雑なロジックがある場合は、自動プロパティを使用しないでください。いつものようにprivate int _ageと通常のgetters/setterに行きます。

あなたは多くのロジックを必要としない
public class TempMessage { 
    public int FromID { get; set; } 
    public int ToID { get; set; } 
    public string Message { get; set; } 
} 

はIMO、自動プロパティをすばやくように使い捨てのオブジェクトまたは一時的なデータのカプセルを実装するための、より適しています。

+0

クラスに複雑なロジックを追加すると、そのクラス内で自動プロパティを使用したかどうかが変わるのはなぜですか? –

+0

より一貫性のあるもの...複雑なロジックを持っている場合は、OOのプラクティスごとにプライベートバッキング変数からアクセスする必要があります。自動プロパティを使用すると、それらにアクセスする際に矛盾が発生しますプロパティ。いくつかは接頭辞のアンダースコアを持ち、いくつかは接頭辞を持たないからです。 – chakrit

92

新しい自動プロパティの目的は、ゲットやセットに特別なロジックを必要としない単純なプロパティを持っているときに書く必要があるボイラープレートコードの量を減らすことです。

あなたはこれらのプロパティを使用してプライベートメンバにアクセスする場合、それはいくつかの理由のために、通常です:

  • あなただけの単純な取得/設定以上に必要 - この場合には、あなただけは避けるべきこのメンバの自動プロパティを使用します。
  • getまたはsetを実行して実際にメンバーを直接使用することを避けたいとします。この場合、実際にパフォーマンスが低下した場合は驚いています。単純なget/setメンバーはインライン化が非常に簡単で、私の(確かに限られた)テストでは、自動プロパティの使用とメンバーへの直接アクセスの違いはありませんでした。
  • 公開リードアクセス(getのみ)を行い、クラスがメンバーに直接書き込むことができます。この場合、自動プロパティでプライベートセットを使用できます。すなわち

    public class MyClass 
    { 
        public int Age {get; private set;} 
    }

これは通常、直接自動プロパティによって使用されるバッキングフィールドに取得したいのための最もな理由をカバーしています。

+0

真実 - 彼らはボウラープレートのコードを減らし、私はあなたがテストする必要があるものを減らすことを広告します。フレームワークを信頼できるので、手動取得/設定をテストする必要があるが自動プロパティはテストしないと主張する人もいます。 –

+3

ここでコードサンプルが間違っています。する必要があります パブリッククラスMyClass { public int Age {get;プライベートセット;} } 私はこの回答に同意します。プライベートフィールドにアクセスすることはできません。必要な場合は、最初に自動プロパティを使用すべきではありません。 – hwiechers

+0

hwiechers、ありがとう、私はその編集があったが、formatingを修正しようとすると、もう一度ペーストして間違ったコードブロックを削除する必要があります。ドー! – Wilka

7

あなたはそうすべきではありません。そうする必要はほとんどありません。プロパティにアクセスする必要がある場合は、publicプロパティ(this.Ageなど)を使用します。パブリックプロパティを支持するプライベートフィールドには何も特別なものはありません。プロパティを使うことはただの迷信です。

+1

私はいつも自動プロパティーのポイントが何であるか疑問に思っていました。ゲッターやセッターに特別なロジックがない場合、なぜそれらを持っているのですか? –

+4

@MatthewLockの柔軟性。ダイレクト・フィールド・アクセスを使用すると、同時にすべてのクライアント・コードを変更しない限り、そのデザインにロックされます。しかし、プロパティを "擬似フィールド"から計算されたプロパティに変更する場合、または設定者または何を持っているかにアサーションとチェックを追加することに決めた場合は、透過的に行うことができます。これは、すべてのクライアントコードを制御することができないライブラリコードを記述する場合に、さらに便利です。 – Wedge

関連する問題