[GoF]-ConcreteSubject 可以覆盖通知方法吗？

Question

我正在模拟一种情况：

• NotificationBox：观察者
• list1、list2、list3：主题

现在我将使用观察者模式制作一张图表来描述每个列表实现不同类型的 notify() 的事实（例如，列表状态的某些变化只需要通知某个观察者，使用一些标准）

我做了类似的东西：

在这种情况下，每个主体都会重写 notify 方法，以便仅根据某些标准通知观察者的某个子集，并使用正确的更新方法。

示例

ListaMDDpubblico 是由某个文件组成的列表，每个文件都有一个特定的标签。当一个文件被加载时，只有与“喜欢”文件标签的用户相关联的notificationBox才应该使用updateMDD来通知。

它对 [GoF] 友好吗？

或者我需要制作3个不同的Subject抽象类，每个都以列表方式实现notify方法？

提前致谢

[编辑]

经过对答案和评论的一些推理，我对这种情况的另一种可能的设计是：

通过这种方式，每个更改都会通知所有订阅的观察者（针对每种不同类型的主题），并且了解是否必须考虑通知的逻辑在由 notificationBox 实现的更新方法中建模（因此现在的通知是广播和每个 ConcreteSubject 不需要对具体观察者一无所知）。

Answer 1

观察者与 GoF 模式的比较

在 GoF 观察者中，notify() 在抽象 Subject 中实现：调用所有观察者的 update() 函数，由他们决定对象更新通知是否相关。这样，主体就不必知道观察者的任何具体信息。

第一个潜在的设计问题

如果您让Subject 决定通知哪个Observer，则主题可能需要了解有关观察者的更多详细信息。根据主体需要了解观察者的决策信息，这可能合适，也可能不合适：

• 如果具体主体需要了解具体观察者，则该设计会以一种不可取的方式增加耦合。事实上，这违背了open/close principle，因为添加新类型的观察者需要调整具体的主题。维修噩梦近在眼前！
• 如果具体主体只需要知道抽象观察者的接口，你的设计就可以了。尽管如此，本着DRY 的精神，我还是建议将此模式与template method pattern 结合起来，让notify() 具有普遍性，并使其依赖于可以根据具体主题而改变的抽象条件。

第二个潜在的设计问题

您的具体观察者似乎需要知道主题的类型才能调用正确的更新函数。我不确定是否真的如此，但这是您对updateXXX() 命名约定的印象，因为每个XXX 仅用于一个主题。

如果是这种情况，Observer 抽象将取决于Subject 的具体实现。这似乎不是一个好主意：具体类可能依赖于抽象类，但相反是违反开/关原则的。

UML 建模问题

在UML图上，我建议不要使用从Subject到Observer的黑色组合菱形：

• 复合（黑色菱形）表示观察者完全属于主体（即如果主体被删除，其观察者将无法生存）。我怀疑这里的情况。
• 聚合（白色菱形）具有相似的含义，但具有共享所有权（非排他性）。我不能排除这一点，但我也没有看到在这里使用它的令人信服的论据。
• 我会推荐一个简单的（一对多）关联。
• 如果您将多重性 1 留在主题一侧，则您的观察者必须在其构建过程中进行注册。这是您打算实施的，还是应该是 0..1 ？

从具体观察者到所有具体主题的可导航关联提出了问题：

• 具体观察者和抽象主体之间是否存在可导航的关联？ （在这种情况下，为了准确起见，绘制与抽象类的关联）
• 或者是否存在 3 个可导航的关联：具体观察者和每个具体主题之间？

考虑这方面的开/关原则。如果您需要添加一个新的具体主题，您希望会发生什么？您是否必须更改所有具体观察者（添加新关联）？还是您希望它在没有任何变化的情况下工作（因为关联与抽象主题有关）？

Answer 2

GoF 书籍第 298-299 页详细讨论了这个问题。我认为上面显示的设计最接近，

明确指定感兴趣的修改。您可以提高更新效率 通过扩展主题的注册接口以允许注册观察者 仅适用于感兴趣的特定事件。当这样的事件发生时，主体 只通知那些对该事件感兴趣的观察者。

不过，GoF 书的实现方式与上面显示的设计略有不同。上述设计扩展了观察者接口以指定每种类型的事件，因此事件类型的知识传播到每个主题（以及每个观察者，如果有多个）。此外，如果将来添加新的事件类型，则会很容易编辑观察者界面。

出于这些原因，我更喜欢使用多个观察者的方法。与其将所有更新方法组合到一个接口中，不如将它们分成GsObserver、MddObserver 和DdlObserver。每个主题只能注册其中一个观察者接口，但NotificationBox 可以实现所有三个。