观察者模式应该包括一些无限循环检测？ [英] should the Observer Pattern include some infinite loop detection?

问题描述

快速浏览GoF和头部设计模式书籍，似乎没有提到观察者模式的无限循环检测和处理？

Quickly going through the GoF and the Head First Design Patterns book, it seems like there is no mentioning of infinite loop detection and handling for the Observer pattern?

我认为如果是2类之间，我们可以更加小心无限循环问题，但是如果有5个类或12个类，并且观察者去多方向。在这种情况下，将不会有一个无限循环，而且这个模式可能会有一些检测？

I think if it is between 2 classes, we can be more careful about the infinite loop problem, but what if there are 5 classes or 12 classes, and the observers go multi-directions. In this case, won't an infinite loop be possible and some detection should be added to this pattern?

推荐答案

无限循环可以（a）观察者也可观察到，（b）他们观察到的变化可能导致自身变化，（c）观察图是循环的，（d）有一种变化可能会导致变化同样的理想的解决方案是设计出无限循环的风险，确保其中一个要求不存在。如果您目前的设计使得所有四项都是真实的，请查看是否可以更改它以使其中的一个为假。

Infinite loops can only happen if (a) Observers are also Observable, (b) changes they observe can lead to changes in themselves, (c) the graph of observation is cyclic and (d) there is a kind of change which can end up triggering a change of the same kind. The ideal solution would be to design out the risk of infinite loops by ensuring one of those requirements is absent. If your current design makes all four true, see if you can change it to make one of them false.

Observer-Observable的传统用途是分层架构 - 实例，其中视图控制器观察模型对象，或者事件处理程序观察GUI组件，而在这里，图形不会是循环的，所以没有无限循环的风险。

The traditional uses for Observer-Observable are in layered architectures - for instance, where view-controllers observe model objects, or where event handlers observe GUI components - and here, the graph will not be cyclic, so there's no risk of infinite loop.

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

I should probably explain about point (d), about different kinds of changes. What i mean is that if you have a situation where, say, a UserInputEvent can trigger a ModelStateChangedEvent, and a ModelStateChangedEvent can trigger a WidgetUpdateEvent, which can't itself trigger anything, then even if the Observers form a cyclic graph, you can never get infinite loops, because there's only a finite number of stages in the sequence of events. Effectively, the events form an acyclic graph, even if the Observers don't. If, however, a ModelStateChangedEvent can trigger another ModelStateChangedEvent, then you have the risk of cycles.

如果你真的不能避免周期的风险，那么你可以偷来自 Jon Postel 的想法，并使每个事件通知进行整数的生存时间计数器。当Observable广播原始事件时，意味着从观察者网络之外进入的事件，并启动其中的级联事件，它将计数器设置为一些适当的初始TTL值。当Observable通过广播另一个事件来响应事件时，它将使用比触发事件小的TTL。当观察者获得TTL为零的通知时，它将忽略它。这将阻止无限循环，但也会阻止Observer对某些事件进行正确响应，所以谨慎使用它是一个想法。我强烈建议，触发TTL限制的事件应该被视为编程错误的结果，并且应该像处理类似NullPointerException或断言失败的方式一样记录和报告。

If you really can't avoid the risk of cycles, then you can steal an idea from Jon Postel, and make every event notification carry an integer time-to-live counter. When an Observable broadcasts an 'original' event, meaning something that comes in from outside the network of Observers and kicks off a cascade of events inside it, it sets the counter to some suitable initial TTL value. When an Observable responds to an event by broadcasting another event, it would use a TTL one less than that of the triggering event. When an Observer gets a notification with a TTL of zero, it ignores it. This would prevent infinite loops, but would also prevent an Observer responding 'correctly' to some events, so it's an idea to be used with caution. I would strongly suggest that an event cascade hitting the TTL limit should be considered the result of a programming error, and should be logged and reported in the same way as you'd handle something like a NullPointerException or an assertion failure.

这篇关于观察者模式应该包括一些无限循环检测？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！