プロパティゲッターで毎回新しいICommandを返すのは悪いですか？だけではなく、新しいオブジェクトを毎回返すの</p> <pre><code>RelayCommand _saveCommand; public ICommand SaveCommand { get { if (_saveCommand == null) { _saveCommand = new RelayCommand(this.Save); } return _saveCommand; } } </code></pre> <p>：

Question

は、コードのこの作品を書くのは、それは価値がある私は、コマンドゲッターはかなりまれにしか使用されません知っていることから、

public ICommand SaveCommand 
{ 
    get { return new RelayCommand(this.Save); } 
} 

とRelayCommandのコンストラクタかなり速いです。より長いコードを書く方が良いでしょうか？オペランドがnullでない場合

Answer 1

私はnull coalescing operator

public ICommand SaveCommand 
{ 
    get { return _saveCommand ?? (_saveCommand = new RelayCommand(this.Save); } 
} 

が好きそれはそれ以外の場合は、右オペランドを返し、左側のオペランドを返します。

Answer 2

このデザインは、あなたのクラスのユーザーには間違いかもしれません。たとえば、数千回の反復でループ内のプロパティの値を読み取ることができます。それは多くの新しいオブジェクトを作成し、ユーザーはおそらくそれを期待しません。

StyleCop警告CA1819: Properties should not return arraysのドキュメントを参照してください - これは非常によく似た問題です。

通常、ユーザーは、このようなプロパティを呼び出すことによるパフォーマンスの悪影響を理解できません。具体的には、プロパティをインデックス付きプロパティとして使用することがあります。

さらに、SaveCommand == SaveCommandはfalseになります。私はこれが直感的ではないと思う。

要約すると、これは最高のデザインではないかもしれませんが、コードのユーザーがどのように動作し、正しく使用するかを知っていれば問題ありません。

Answer 3

はい、毎回新しいオブジェクトを返すのは悪いことです。それはなぜですか？何らかの理由でゲッターが何度も呼び出されると、毎回新しいオブジェクトがメモリに作成されます。これを単なるインスタンスのために行うと、それはそれほど恐ろしいことではありません。しかし、このようなプログラミングの習慣を覚えると、見つけにくい問題を作り出し、維持しがたいコードベースを持つことになります。シンプルで清潔でエレガントで、いつも優しく、素敵で清潔で保守しやすいコードベースで終わる方が良いです。あなたはそれを宣言する際ところで

、あなたは常にだけのフィールドを初期化することができます：

RelayCommand _saveCommand = new RelayCommand(this.Save); 

を次に、あなたのゲッターは、それだけでこれを必要とします。

return _saveCommand;