属性获取器是否应该返回私有成员以外的值？答案

【问题标题】：Should property getters return values other than that of the private member?属性获取器是否应该返回私有成员以外的值？
【发布时间】：2011-06-29 06:13:21
【问题描述】：

private int _myField;
public int MyField
{
  get {
   return _myField * 99;
}
set {
   _myField * value;
}
}

我见过开发人员将更复杂的代码添加到 Getter 中，设置其他成员和属性等。对我来说，返回关联成员变量以外的值会导致调试混乱。

这样更好吗？

private int _myField;
public int MyField
{
  get {
   return _myField = _myField * 99;
}
set {
   _myField * value;
}
}

还是这个？

private int _myField;
public int MyField
{
  get {
   return _myField;
}
set {
   _myField = value * 99;
}
}

【问题讨论】：

两者都对我来说很糟糕，因为MyField=MyField 不是一个空操作。（而且我不是反对者）

标签： .net properties code-formatting

【解决方案1】：

这些都不好。在某些情况下可以设置其他成员、执行缓存等 - 毕竟，没有规则说属性必须只由没有逻辑的成员变量支持，而验证是其中之一您需要其他逻辑的好例子。

但是，通常不是写一个属性是一个好主意，以便获得一个你刚刚设置的值会给出一个完全不同的答案。特别是，

foo.SomeProperty = foo.SomeProperty;

应该几乎从不做任何重要的事情（而在你的例子中它会改变价值）。

（话虽如此，前两个示例的设置器代码已损坏。）

【讨论】：

【解决方案2】：

我认为您的第二个 sn-p 完全违反了代码的语义。使用 getter 不应影响公共值 - 也就是说，您可以在 getter 内部做任何您想做的事情，例如缓存或延迟初始化等 - 但在外部，对 getter 的两次连续调用应该返回相同的结果。

【讨论】：

感谢大家的回复。我同意该属性在调用时应返回相同的值，因此第二个示例尤其会引起问题。在这里引起混淆的实际情况是复杂的代码路径，其中 getter 正在设置其他属性，这些属性反过来对它们进行一些验证，如果验证失败，则初始属性的成员变量永远不会被设置。我相信通过复杂的代码路径。将设置代码重构为 Setter 或其他东西并让 getter 获取结果字段是更好的做法。

【解决方案3】：

嗯，属性存在的原因之一是你可以做这样的事情。属性是一种封装形式，使您能够隐藏任何需要对调用者隐藏的逻辑。

我个人的理念是，像您这样的东西很好（即不会产生副作用的简单数据操作），但是一旦逻辑变得比几行更复杂，您应该转换为向调用者指示的方法更多的事情正在发生。

【讨论】：