3 
class Student
{  
     private string firstName;

     public string FirstName
     {
        get
        {
            return firstName;
        }
        set
        {
            firstName = value; // Possible logical checks may be implemented here in the future
        }
     }

     public Student (firstName)
     {

         this.firstName = firstName; // Option 1
         // Or
         FirstName = firstName; // Option 2

     }
 }

2 つの行のうち、どちらがより標準的ですか?

コンストラクターでプライベート メンバーとパブリック メンバーのどちらを使用しますか?

4

6 に答える 6

9

オプション3で行くことができます

 public string FirstName {get; set;}
 public Student (firstName)
 {
     FirstName = firstName;
 }
于 2013-07-10T18:27:31.210 に答える
5

それは依存します...多くの場合、例に含まれていないものに依存します。まず、プロパティ全体を自動実装プロパティに短縮できます。

public string FirstName { get; set; }

この場合、これは質問を無意味にします。それを超えて、問題は、プロパティに (現在または将来) 存在する可能性があるロジックの種類と、そのロジックをコンストラクターによって呼び出す必要があるかどうかに帰着します。

たとえば、プロパティは必要な値を内部的にチェックするか、またはその他の検証を実行しますか? このようなもの：

private string firstName;
public string FirstName
{
    get { return firstName; }
    set
    {
        if (string.IsNullOrWhiteSpace(value))
            throw new ArgumentNullException("FirstName");
        firstName = value;
    }
}

このような場合、オブジェクトの構築時にロジックが適用されるように、バッキング フィールドではなくプロパティをコンストラクターで使用する必要があることは明らかです。

逆に、セッターにアクセスするときだけ使用し、オブジェクトを作成するときは使用しないロジックがある場合があります。私の頭の中では、場所に関する情報を保持するオブジェクトが 1 つの例として考えられます。これには Address プロパティと Coordinates プロパティが含まれる場合があり、それらのいずれかが変更されるたびに、新しい値を地理的に特定し、もう一方を更新するバックエンド プロセスが存在します。ただし、(おそらくデータベースから既存の Location を再構築する場合) 両方を受け入れるコンストラクターがあり、構築中に地理位置情報を実行しても意味がありません。その場合、プロパティではなくバッキング フィールドを設定します。

プロパティを使用しないという説得力のある理由がないため、一般的にはバッキング フィールドの代わりにプロパティを使用することを好みます。単純に、後ですべてのアクセサーが使用するロジックがこれらのプロパティに追加される可能性があるためです。また、プロパティにはバッキング フィールドよりも意味のある名前が付けられている可能性が高い (たとえば、FirstNameより読みやすく/意味がある_firstName) ため、コードの残りの部分を可能な限り読みやすく保ち、より読みやすい名前を優先することが優先されます。 .

于 2013-07-10T18:35:20.963 に答える
0

場合によります：

 private string firstName;
 public string FirstName
 {
    get
    {
        return firstName;
    }
    set
    {
        firstName = (value=="mycheck")?"default":value;
    }
 }

プロパティにいくつかの検証がある場合は、次のことを行う必要があります。

 public Student (firstName)
 {
     FirstName = firstName;
 }
于 2013-07-10T18:32:45.330 に答える
0

些細な POCO (Plain Old CLR Objects) を作成するときは、次のアプローチを使用します。

public class POCO
{
    public POCO()
    {
        Name = "Moo-Juice";
    }

    public string Name { get; set; }
}

メンバー変数が実際に必要な重要なケースでは、プレフィックスを付け_ます (これはインテリセンスに役立ち、メンバーとローカルを区別できるようになります)。

public class NonTrivial
{
    private string _name;

    public NonTrivial()
    {
        _name = "Jon Skeet";  // He is non-trivial
    }
}

this.このようにして、コードをどこでも汚染することを避けます。

于 2013-07-10T18:30:38.597 に答える
0

最も一般的なのはプロパティを使用することですが、選択の問題です。

この場合は特に、自動プロパティを使用する必要があります。

public string FirstName { get; set; }

また、コンパイラはバッキング フィールドを自動的に追加します。

C# 3.5 (IIRC) 以降では、自動初期化子を使用できるため、パラメーター コンストラクターを追加しないことも選択できます。

new Studant() { FirstName = "John Doe" }

コンストラクターを呼び出し、プロパティを 1 行で設定します。

全体として、私は実際に依存するものに対してのみコンストラクターパラメーターを要求する傾向があり (依存性注入を参照)、永続化する前に検証するなど、常に必要ではないものは必要になるまでオプションにします。

于 2013-07-10T18:35:23.073 に答える