“One Shot”属性获取器是不是被认为是.NET（或一般而言）中可接受的编码标准[关闭]

Posted 2023-03-10

【中文标题】“One Shot”属性获取器是不是被认为是.NET（或一般而言）中可接受的编码标准[关闭]

【英文标题】：Are "One Shot" Property Getters considered an acceptable coding standard in .NET (or in general) [closed]“One Shot”属性获取器是否被认为是.NET（或一般而言）中可接受的编码标准[关闭]

【发布时间】：2012-08-06 13:51:03

【问题描述】：

最近在使用 C# 和 ActiveMQ（通过 Apache.NMS 库）进行一些工作时，我在 ActiveMQBytesMessage 上遇到了以下属性

public new byte[] Content

  get
  
    byte[] buffer = (byte[]) null;
    this.InitializeReading();
    if (this.length != 0)
    
      buffer = new byte[this.length];
      this.dataIn.Read(buffer, 0, buffer.Length);
    
    return buffer;
  
  ..(setter omitted)

InitialiseReading 方法处理数据从活动 MQ 到 .dataIn 字段的连接和流式传输。但问题是 它每次都这样做。一旦读取了该数据，就再也无法读取它，并且 dataIn 字段被置零并重置。因此，只需观察属性并再次观察它，您就会丢失数据。这导致了一些非常奇怪的错误，例如：

byte [] myBytes = new byte[msg.Content.Length]; 
//Touched the property. Data read in.

msg.Content.CopyTo(myBytes,0); 
//Uh oh! touched it again, copying a zero'd array.

或者当您在调试时将监视变量卡在属性上或不小心将鼠标悬停在属性上。

这种机制是为流数据使用属性的公认或流行方式吗？

【问题讨论】：

虽然您在这个问题上花了一些时间，但我认为没有建设性的答案。

是的，就征求意见而言，这有点“主观”。也许我今天早上只是在发泄对 SO 的挫败感 :-) 如果它关门了。就这样吧。

您可以创建一个单元测试并在项目中打开一个错误，而不是在这里抱怨，然后其他人可能会从您的经验中受益。

这是个好问题。它确实有一个非常有建设性的答案。它涉及编写清晰的可维护代码的最佳实践。您可以从答案中清楚地看到，实际上是有共识的。

【参考方案1】：

非常非常糟糕的代码。

普遍的看法是属性不应该影响对象的内部状态。如果你调用 set，那么 get 你应该总是取回你刚刚设置的值。如果你调用 get twicwe，你应该两次得到相同的结果。

这至少应该是一个名为GetContent的方法，但id仍然希望能够重复调用该方法并获得相同的结果。

【参考方案2】：

这是非常糟糕的代码。 属性应该包含很少的逻辑，并且绝不会产生副作用。

这个属性最好作为一个名为getNextContent 的方法。

【参考方案3】：

它的代码很糟糕，它破坏了一个叫做命令查询分离 (CQS) 的东西。

这个想法是查询应该是可重复的，没有任何副作用。命令/动作不应真正提供有关对象的任何信息，只需进行修改即可。 （虽然实际上它可以用于链接命令）

【参考方案4】：

很明显，它的代码很糟糕，而且我还没有看到太多。

【参考方案5】：

显然，由于您给出的原因，这是一个糟糕的代码。

【参考方案6】：

你应该提交一个错误。不管他们修复它的可能性有多大。