5

最近在使用 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.

或者当您在调试时，您在属性上放置了一个监视变量或不小心将鼠标悬停在属性上。

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

4

6 回答 6

6

非常非常糟糕的代码。

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

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

于 2012-08-09T10:50:50.717 回答
2

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

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

于 2012-08-09T10:54:10.043 回答
2

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

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

于 2012-08-09T10:54:40.543 回答
1

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

于 2012-08-09T10:50:31.950 回答
1

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

于 2012-08-09T10:51:57.337 回答
1

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

于 2012-08-09T11:55:59.617 回答