design-patterns - 观察者模式是否应该包括一些无限循环检测？

Question

快速浏览 GoF 和 Head First Design Patterns 一书，似乎没有提到观察者模式的无限循环检测和处理？

我觉得如果是在2个类之间，我们可以更小心地解决无限循环问题，但是如果有5个类或12个类，观察者去多方向呢？在这种情况下，是不是无限循环是可能的，并且应该在此模式中添加一些检测？

Answer 1

无限循环只有在(a)观察者也是可观察的，(b)他们观察到的变化会导致自身发生变化，(c)观察图是循环的，(d)有一种变化可以结束时才会发生引发同类变化。理想的解决方案是通过确保不存在这些要求之一来设计出无限循环的风险。如果您当前的设计使所有四个都为真，请查看您是否可以更改它以使其中一个为假。

Observer-Observable 的传统用途是在分层架构中——例如， View Controller 观察模型对象，或者事件处理程序观察 GUI 组件——在这里，图不会是循环的，所以不存在无限循环的风险。

我可能应该解释一下 (d) 点，关于不同种类的变化。我的意思是，如果你有这样的情况，比如说，一个 UserInputEvent 可以触发一个 ModelStateChangedEvent，一个 ModelStateChangedEvent 可以触发一个 WidgetUpdateEvent，它本身不能触发任何东西，那么即使观察者形成一个循环图，你也永远不能得到无限循环，因为在事件序列中只有有限数量的阶段。实际上，事件形成了一个无环图，即使观察者没有。但是，如果 ModelStateChangedEvent 可以触发另一个 ModelStateChangedEvent，那么您就有循环的风险。

如果你真的无法避免周期的风险，那么你可以从Jon Postel窃取一个想法。 ，并使每个事件通知都带有一个整数生存时间计数器。当 Observable 广播一个“原始”事件时，这意味着从观察者网络外部进来的东西并在其中启动一系列事件，它会将计数器设置为某个合适的初始 TTL 值。当 Observable 通过广播另一个事件来响应一个事件时，它将使用比触发事件小 1 的 TTL。当观察者收到 TTL 为零的通知时，它会忽略它。这将防止无限循环，但也会防止观察者对某些事件“正确”响应，因此谨慎使用它是一个想法。我强烈建议应将达到 TTL 限制的事件级联视为编程错误的结果，并且应以与处理 NullPointerException 或断言失败之类的方式相同的方式进行记录和报告。