观察者模式：事件处理器会影响主体执行吗？

Question

观察者模式有几种形式：听众，事件等（我是对的吗？）

但是今天我们发现团队成员之间没有达成协议 - Listener（Observer）是否可能会影响调用它的方法的执行。

这个例子的建议如下：当交易通过DealDao保存时，它可以触发一个将被一些监听器捕获的事件：

• 更新交易中的计算字段（一些费用等）;
• 创建一些依赖实体。

我自己非常不喜欢这种方法 - 例如，因为如果侦听器中依赖实体的更新引发异常，那么交易更新也应该回滚。

但是听众迫使主体回滚似乎不自然。

Answer 1

通常，如果您要更改对象的行为，那么您可能正在实施策略模式而不是观察者模式。

修改模型本身以响应观察到的事件可能导致非常复杂的行为，所以我不会真的推荐它，但它是有效的。

通常会尝试通过您的系统考虑数据和操作的“流程”。如果你可以让流程始终朝着一个方向（或者至少有尽可能少的循环）那么整个事情变得更容易管理和理解。

添加观察者是原始数据的“向下流”。如果该观察者然后返回并修改原始数据然后流向上游并使整个程序的行为更加复杂。例如，如果该更改然后触发另一个事件，然后再次返回到同一个观察者，等等会发生什么？跟踪执行的人会发现意外的数据更改，直到他们发现观察者并且你遇到了堆栈溢出和各种类似的有趣游戏的递归循环的可能性。

Answer 2

如果没有DealDao的听众，交易是否会被保存？

如果是，那么你实际上有一个隐式监听器，它实际上是保存操作。然后，当添加另一个更新交易中的字段的监听器时，我们有两个监听器对同一个对象进行操作。这显然违反了可能导致问题的封装原则。但观察者模式并非徒劳：相似，你可以通过其他方式获得相同的效果。正如用户Tim B指出的那样，首先设计具有最少循环的数据流，即作为具有节点和边的图，并且让每个节点是明确定义的对象（在OOP意义上）。只有在那之后，想一想如何实现它，Observer Pattern是一个有效的选项。