16

自動プロパティはカプセル化を破るので、やや悪であるというMarkSeemanの考えに同意します。しかし、私はそれらがもたらす簡潔な構文、読みやすさ、便利さが好きです。

私は引用します：

public string Name { get; set; }

コードスニペットの問題は、セレモニーが多すぎることではありません。問題は、カプセル化が壊れることです。実際には

「[…]ゲッターとセッターは、カプセル化や情報隠蔽を実現しません。これらは、言語に合法化された方法であり、それらに違反します。」</ p>

James O. Coplien＆GertrudBjørnvig。リーンアーキテクチャ。ワイリー。2010.p。134。

ほとんどの場合、null以外のガード句を追加することは、プロパティセッターにとって十分であり、以下のいずれかよりも優れた方法があるかどうかを知りたいと思います。より良いのは、より簡潔で反復性の少ない方法を意味します。

コードコントラクトの使用：

private string _username;
public virtual string Username
{
    get { return _username; }
    set 
    {  
        Contract.Requires(value != null);
        _username = value; 
    }
}

バニラ.NETの使用：

private string _username;
public virtual string Username
{
    get { return _username; }
    set 
    {
        if (value == null) throw new ArgumentNullException("Username");
        _username = value; 
    }
}
4

3 に答える 3

7

コード契約マニュアル、§2.3.1を引用します。

public int MyProperty { get; private set ; }

[ContractInvariantMethod]
private void ObjectInvariant () 
{
      Contract. Invariant ( this.MyProperty >= 0 );
      ...
}
于 2011-07-21T21:29:21.130 に答える
0

ユーザーの観点からは、プロパティは単なるメモリバッファであると思います。メソッド（アクション）がユーザーコードで呼び出された場合にのみ、プロパティバッファーの有効性をチェックする必要があります（たとえば、nullチェックは例外をスローします）。

割り当てられたデータが（アルゴリズム設計で）有効でない場合、プロパティセッターは内部メンバーに無効な値を配置する必要があります。エラーチェックとリターンは、このプロパティ値を使用するメソッドから取得する必要があります

于 2011-07-21T08:33:00.297 に答える