Question

编写这段代码是否值得：

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

而不是每次只返回新对象：

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

据我所知，命令getter的使用非常少，RelayCommand的构造函数非常快。编写更长的代码会更好吗？

Answer 1

我喜欢null coalescing operator

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

如果操作数不为null，则返回左侧操作数，否则返回右操作数。

Answer 2

此设计可能会让您的班级用户误导。例如，他们可以在循环中读取属性的值，并进行数千次迭代。这将创建许多新对象，用户可能不会期望这样。

请参阅StyleCop警告CA1819: Properties should not return arrays的文档 - 这是一个非常类似的问题。

通常，用户不会理解调用此类属性会对性能产生负面影响。具体来说，他们可能会将该属性用作索引属性。

此外，SaveCommand == SaveCommand将为false。我认为这是违反直觉的。

总而言之，这可能不是最好的设计，但是，如果您的代码的用户知道它的工作原理以及如何正确使用它，那就没关系。

Answer 3

是的，每次都返回一个新对象是不好的。为什么这样？如果由于任何原因，多次调用getter，那么每次都会在内存中创建新对象。如果你只为这个孤立的实例做到这一点，那就不那么可怕了。但是如果你养成以这种方式编程的习惯，你就会创建难以发现的问题并拥有一个难以维护的代码库。最好是在任何时候都要简单，干净和优雅，最终得到一个漂亮，干净，易于维护的代码库。

顺便说一句，您可以在声明时始终初始化该字段：

RelayCommand _saveCommand = new RelayCommand(this.Save);

然后你的吸气器只需要它：

return _saveCommand;

每次在财产获取者中返回新的ICommand是不是很糟糕？

3 个答案: