コンストラクタは、プライベートメンバまたはパブリックフィールド（C＃centric）を介して、独自のパラメータを直接初期化する必要がありますか？

Question

など。編集

class Foo { 
private string _Bar ; 
    Foo (string bar) 
    { 
    _Bar = bar ; 
    } 
public string Bar 
{ 
    get { return _Bar ; //more logic here 
    } 
    set { _Bar = value ; //more logic could be added 
    } 
} 
} 

OR

class Foo { 
private string _Bar ; 
    Foo (string bar) 
    { 
    this.Bar = bar ; 
    } 
public string Bar { 
    get { return _Bar ; //more logic could be added } 
    set { _Bar = value ; //more logic could be added }} 
} 

優れている方法である：私は、後者はそれにいくつかのより多くのロジックを配置することができます、まだそれはそれのためにそれを使用することが正当化される...

ことを知っています

Answer 1

どちらの方法でもクラスに意味があります。 「ベストプラクティス」はありません。

場合によっては、プロパティと同じ操作しか実行しないようにすることもできます。その場合は、プロパティを使用することが理にかなっています。

は時々、あなただけのあなたはそれがフィールドを使用することは理にかなっている場合には財産ポスト建設、経由して行うことができます物事に違反し、コンストラクタで行うことができることをやりたいです。

Answer 2

です。

私は、副作用がない場合はプロパティを使用することをお勧めします。しかし、プロパティを設定すると、イベント通知、潜在的に不必要な（この時点で）検証などの他の副作用がある場合があります。そのような場合は、バッキングフィールドを直接設定する方が適切です。

Answer 3

パブリックプロパティのロジックを実行する必要がある場合は、そのメソッドを使用します。あなたがまっすぐな割り当てをしているだけの場合は、プライベートメンバーに割り当てても問題ありません。

Answer 4

エリックリペットすることにより、この優れたブログの記事をお読みください：Automatic vs Explicit Properties：

ユーザー：

ここで私は、昨年のC＃ユーザー から、私は頻繁にかなり を得る質問を得た質問です： 「通常の」明示的なプロパティでは、 クラスの中から専用の バッキングフィールドを直接使用する傾向があります。もちろん、自動 プロパティでは、これを行うことはできません。私 の懸念は、私が 何らかの理由で明示的にプロパティを必要とする決定 場合、将来的に、私は新しいプライベート フィールドを使用するクラス 実装を変更する 選択肢が残ってるということである、または介さ続けます プロパティ。この場合、右の のことが何であるか分かりません。

あなたは「何らかの理由で」と言いますが、その鍵は です。あなたの 質問への答えは理由が 変化が動機ということだったか に完全に依存します。内 からプロパティにアクセスするときに 希望セマンティクス かどうかを評価する必要があります

やる気が自動的から 変更は明示的に プロパティを実装するために プロパティを実装している理由は、プロパティの意味 を変更した場合は、クラスは、クラス外の のプロパティにアクセスするときは、 と同じで、目的のセマンティクス とは異なります。 [重点鉱山]

Answer 5

それは私が唯一の場所（プロパティのセッター）で私の検証を書くことができますように私は、多くの場合、プロパティを使用します。重複するコードを避けるのに役立ちます。

public class Foo 
{ 
    private string _Bar = String.Empty; 

    public string Bar 
    { 
     get { return _Bar; } 
     set 
     { 
      if (value == null) 
      throw new ArgumentNullException("Bar"); 
      _Bar = value; 
     } 
    } 

    public Foo(string bar) 
    { 
     Bar = bar; 
    } 
} 

Answer 6

あなたの例では、少しも簡単ですが、あなたのコメントのセットの宿泊施設には、プライベート変数への単純な割り当てよりも複雑かもしれないという可能性を暗示「//より多くのロジックを追加することができます」。

プロパティセットに同じロジックを既にコーディングしている場合は、コンストラクタで同じロジックを繰り返さないでください。これは不要なコードの重複であり、ロジックを変更する必要があるときにエラーが発生しやすく、将来コードを管理しなければならない開発者の痛みです。

setプロパティにイベント通知のようなコンストラクタで望ましくない/不要な副作用がある場合は、共通コードを独自のメソッドにリファクタリングする必要があります。コンストラクタとsetプロパティは、どちらもこのメソッドを呼び出すことができます。

あなたは「それは依存しています」という回答をたくさん得ようとしています。その理由のいくつかは、個人的な好み（しばしば、何かが維持またはバギーが難しい過去の経験によって決定される）になるだろう。なぜなら、すべての状況が異なる理由と、コードで実装する一般的なパターンやタスクが多いのに対し、コーディングソリューションでは、常に創造的または革新的であるという規範に従わない可能性があります。問題。私たちはコードをプログラムしないことを忘れないでください。コードをツールとして使用してソリューションをプログラムします。

Answer 7

私は、「依存している」答えに肉体を入れます：内部状態が一貫していることと、コードの重複と、パフォーマンスとのバランスをとることを試みています。

あなたの現在の例が非常に単純なので、私はアダムPに同意します。本当に関係ありません。

readonly変数QuxがBarと他のメンバーBazに依存する例を考えてみましょう。 Quxは計算にかなりの費用がかかりますので、その場で実行する必要はありません。これは、状態を格納するプライベートフィールドを示し、IFF BarとBazの変更を変更します。

したがって、コンストラクタでは、Quxが2回解決されることを知って、BarとBazを公開したり、コンストラクタの終わりまでQuxの解決を延期したり（Qux解決呼び出しを1つ保存する）、公開することができます。

単純なプライベートフィールドを裏付けるパブリックプロパティなど、変更される可能性が低いかなり簡単なコードでは、1つのスタイルを選択してそれに固執し、プログラムの実際の問題を解決することに集中します。