INotifyPropertyChanged 设置器样式

Question

为了将数据的更改反映到 UI，您必须实现 INotifyPropertyChanged，好吧。如果我在大多数情况下查看示例、文章、教程等，那么设置器看起来就像这样：

public string MyProperty
{
  //get [...]
  set
  {
    if (_correspondingField == value)
    {
      return;
    }
    _correspondingField = value;
    OnPropertyChanged("MyProperty");
  }
}

到目前为止没有问题，只有在必要时才引发事件，酷。但是你可以将这段代码重写为：

public string MyProperty
{
  //get [...]
  set
  {
    if (_correspondingField != value)
    {
      _correspondingField = value;
      OnPropertyChanged("MyProperty");
    }
  }
}

它应该做同样的事情（？），你只有一个返回位置，它是更少的代码，它是不那么无聊的代码，它更切中要点（“仅在必要时才采取行动” vs “如果没有必要什么也不做，反之亦然”）。

那么，如果第二个版本比第一个版本有它的优点，为什么我很少看到这种风格呢？我不认为自己比那些编写框架、发表文章等的人聪明，因此第二个版本必须有缺点。还是说错了？还是我想太多了？

提前致谢

Answer 1

我个人认为第二个例子更具可读性。我认为第一个示例变得普遍的原因之一是 Resharper 会提示使用这种样式（并自动进行转换），其理由是它“减少嵌套”。这是正确的，但在像这样的简单情况下，我认为可读性更重要。

这归结为一个根本性的意见分歧——有些程序员认为应该只存在一个“返回”——方法末尾有一个退出点。还有一些人认为，如果可能的话，应该始终有一个“提前退出”，这可能会导致整个方法中出现多次“返回”。你更喜欢哪一个？ :)

Answer 2

我比第一种更频繁地看到第二种风格......但无论如何，这并不重要，行为是完全相同的。不，我认为第二种方法没有任何缺点。这只是个人喜好问题，选择您认为最可读的。

Answer 3

与托马斯·莱维斯克相同。我在代码中使用了第二个，而且我经常看到它。两种方法应该执行相同的操作。

Answer 4

它减少了嵌套。

在您的示例中，它非常清晰，这只是一个品味问题，但是当以连续方式使用时会更加清晰，正如您在此处看到的：

反转“if”语句以减少嵌套

通常我不关心当值相同时是否收到事件，所以我把这部分省略了：

public string MyProperty
{
  get { return _correspondingField; }
  set { _correspondingField = value; OnPropertyChanged("MyProperty"); }
}