0

私が最近責任を引き継いだいくつかのコードで、元の開発者が次のようなことをしたいくつかのインスタンスを見つけました。

protected MyEnumerationType _foo;

public MyEnumerationType Foo
{
    get { return _foo; }
    set { this._foo = (MyEnumerationType) value; }
}

これは私には不必要に冗長に思えます。単に自動プロパティを使用する代わりに、これを行うことに何らかの利点があるかどうかについて興味があります。

public MyEnumerationType Foo { get; set; }

私は何かが足りないのですか？上記のコードの最初のセクションに、私が気付いていない利点はありますか？

4

2 に答える 2

2

元のコードは、C＃3.0がリリースされる前に作成された可能性があります。これは、自動実装されたプロパティが導入されたときです。言語の以前のバージョンでは、最初のアプローチが可能だった唯一のアプローチです。

C＃3.0以降では、バッキングフィールドを明示的に定義する主な利点は、デフォルト値で初期化する（コンストラクターを介して実行する必要がある）など、プロパティでは不可能な操作を実行することです。揮発性として。

于 2012-05-15T18:35:07.467 に答える
1

ドメイン内にあるかどうかわからないので、そのクラスから派生したクラスが field にアクセスできると思われる場合は、このMyEnumerationType _foo方法で (何らかの理由で) プロパティ経由でアクセスすることを避けてください。

あなたの特定の文脈で何らかの意味があるかどうかを言うのは難しいですが、繰り返しますが、上記の意味がある可能性があります.

たとえば、次のようにします。

public MyEnumerationType Foo
{
    get { return _foo; }
    set { 
           this._foo = (MyEnumerationType) value; 
           TriggerSomething(..);
       }
}

そのプロパティを設定すると、自分の環境でいくつかのアクションがトリガーされます。フィールドに直接アクセスすると、子クラスからそのフィールドを変更した場合に、不要な (アーキテクチャ上の決定のための) トリガーを回避するのに役立ちます。

于 2012-05-15T18:32:39.327 に答える