自動実装プロパティについて学ぶ

StackOverflow https://stackoverflow.com/questions/165575

質問

自動実装されたプロパティを使用した単純なクラスがあります：

Public Class foo
{
    public foo() { }  

    public string BarName {get; set;}
}

明らかに、クラス全体で変数BarNameを使用していますが、プロパティ値が設定されたときにロジックを追加する必要があります（すべて大文字である必要があります、図を参照）。これは、BarNameのプライベート変数を作成する必要があることを意味しますか？ _BarName、およびクラス全体で使用されている現在のBarName変数を_BarNameに変更しますか？ 

Public Class foo
{
    public foo() {}  

    private string _BarName = "";
    public string BarName 
    { 
        get {return _BarName;}
        set {_BarName = Value.ToString().ToUpper();}
    }
}

自動実装されたプロパティを使用することの意味と、何かを変更する必要がある場合/変更する必要がある場合に、今後どうなるかを確実に理解しようとしています。上記のリファクタリングはではないことを前提としています。プロパティが基本的に同じままであるため、破壊。クラス内でそれを維持し、必要なロジックを追加するには、クラス内で少し作業するだけです。

別の例としては、セッターまたはゲッターを使用するときに何らかのメソッドを呼び出す必要がある場合があります。さらに値を変更します。

これは、プロパティを設定するためのコードの行と行の公正なトレードオフのようです。

役に立ちましたか？

解決

  

これは私が今する必要があることを意味   BarNameのプライベート変数を作成します

はい

  

現在のBarNameを変更します   クラス全体で使用される変数

作成した新しいプライベート変数を使用するように、クラスの残りのコードを変更しないでください。 BarName は、プロパティとして、プライベート変数を（特に）非表示にすることを目的としています。これは、コードの残りの部分に意図する大幅な変更を回避するためです。

  

リファクタリングは、   上に示したように、重大な変更ではありません   プロパティは基本的に   同じまま;それはちょうどかかった   そのように保つための少しの作業と   必要なロジックを追加します。

正しい。

他のヒント

何も変更する必要はありません。自動実装プロパティは、単なる構文糖です。コンパイラは、舞台裏でプライベート変数とget / setロジックを生成しています。独自のゲッター/セッターロジックを追加すると、コンパイラは自動生成コードの代わりにコードを使用しますが、そのプロパティの users に関する限り、何も変更されていません。プロパティを参照するコードは引き続き機能します。

自動プロパティを使用する場合、基になる「バッキング」に直接アクセスすることはできません。変数を使用すると、プロパティgetterおよびsetterで実装される実際のロジックにアクセスできません。プロパティにのみアクセスできます（したがって、コード全体でBarNameを使用します）。

セッターに特定のロジックを実装する必要がある場合、自動プロパティを使用できなくなり、「古い」形式でプロパティを実装する必要があります。方法。この場合、独自のプライベートバッキング変数を実装する必要があります（少なくとも、私にとって好ましい方法は、プライベートバッキング変数にプロパティと同じ名前を付けることですが、最初の小文字（この場合、バッキング変数の名前はbarNameになります。その後、ゲッター/セッターに適切なロジックを実装します。

あなたの例では、それは重大な変更ではないことは正しいです。このタイプのリファクタリング（自動プロパティから「通常」プロパティへの移動は、パブリックインターフェース（パブリックプロパティの名前またはアクセシビリティ）を変更しないため、重大な変更になることはありません。

そのオブジェクトを検証することがわかっている場合は、自動プロパティを使用しないでください。これらのオブジェクトはドメインオブジェクトなどです。Customerクラスがある場合は、名前や誕生日などを検証する必要があるためプライベート変数を使用します。検証が実行されておらず、クラスはデータを保持するためにのみ使用されるためです。

リファクタリングについては正しいので、実際に何も壊してはいけません。

クラス内の参照をプロパティ名に実際に参照し、プライベートフィールドを参照するように変更する必要があるかどうかは、内部コードがデータの基になる表現にアクセスする必要があるかどうかによって異なりますクラスの消費者に提示されました。ほとんどの場合、十分に放置することができます。

単純な例では、十分にそのままにして、クラス内部のコードがセッターで実行されている変換/フォーマットを破壊できないようにすることが賢明です。

一方で、ゲッターがフィールドの内部表現を消費者がデータを表示するのに必要な方法に変更するためのマジックを行っていた場合、おそらく（場合によっては）クラス内の内部コードはフィールドにアクセスする必要があります。

クラス内の自動プロパティへのアクセスが発生するたびに、フィールドに触れるかプロパティを使用するかを決定する必要があります。

自動プロパティは単なる構文上のシュガーであり、コンパイラは実際にプライベートメンバーを作成しますが、コンパイル時に生成されるため、アクセスできません。

その後、プロパティのゲッターとセッターを実装する場合は、明示的なプライベートメンバーを作成してロジックを追加します。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top