Observer模式有几种化身：监听器、事件等(我说得对吗？)
但今天，我们发现团队成员之间没有达成一致——Listener(Observer)是否可能影响调用它的方法的执行
示例如下：当通过DealDao保存交易时，它可能会触发一个事件，该事件将被某个侦听器捕获，该侦听器将：
- 更新交易中的计算字段(一些费用等)
- 创建一些依赖实体
我自己非常不喜欢这种方法，例如，因为如果侦听器中依赖实体的更新引发异常，那么交易更新也应该回滚。
但是，Listener强迫主题回滚似乎是不自然的。
通常，如果您正在更改对象的行为，那么您可能正在实现策略模式，而不是观察者模式。
根据观察到的事件修改模型本身可能会导致非常复杂的行为，所以我不会真正推荐它，但它是有效的。
一般来说，试着思考数据和操作在系统中的"流动"。如果你能让流程总是朝着一个方向发展(或者至少有尽可能少的循环)，那么整个事情就会变得更容易管理和理解。
添加一个观察者是原始数据的"下行流"。如果观察者返回并修改原始数据，那么它就会向上游流动，并使整个程序的行为变得更加复杂。例如，如果这种变化触发了另一个事件，然后又回到同一个观察者身上，会发生什么？跟踪执行过程的人会发现意外的数据变化，直到他们找到那个观察者，你就会发现可能出现堆栈溢出的递归循环以及各种类似的乐趣和游戏。
如果DealDao没有监听器，交易会被保存吗？
如果是，那么您实际上有一个隐式侦听器，它实际上执行保存操作。然后，当添加另一个监听器来更新交易中的字段时，我们就有两个监听器在同一个对象上操作。这显然违反了封装原则，可能会导致问题。但观察者模式并没有白费：类似的，你们也可以通过其他方式得到同样的效果。正如用户Tim B所指出的，首先设计具有最小循环的数据流，即具有节点和边的图，并让每个节点都是定义良好的对象(在OOP意义上)。只有在那之后，考虑如何实现它，Observer Pattern是一个有效的选择。