Design patterns [GoF]-ConcreteSubject是否可以覆盖notify方法？

我正在模拟一种情况，其中有：

• 通知框：观察者
• 列表1，列表2，列表3：受试者

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

我做了一些类似于：

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

例子 listamdpubblico是由某个文件组成的列表，每个文件都有一个特定的标记。加载文件时，应使用updateMDD仅通知与用户关联的“喜欢”文件标记的通知框

是不是很友好

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

谢谢，这是事先准备好的

[编辑] 在对答案和评论进行了一些推理之后，我对这种情况的另一种可能设计是：

---

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

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

明确指定感兴趣的修改。可以提高更新效率 通过扩展受试者的注册界面，允许注册观察者 仅适用于感兴趣的特定事件。当此类事件发生时，主体 仅通知对该事件感兴趣的观察员

然而，GoF书籍实现这一点与上面所示的设计略有不同。上面的设计扩展了观察者界面，以指定每种类型的事件，因此事件类型的知识传播到每个主题（以及每个观察者，如果有多个）。此外，如果将来添加新的事件类型，则可能会编辑观察者界面

出于这些原因，我更喜欢使用多个观察者的方法。与其将所有更新方法组合到一个界面中，不如将它们分为

GsObserver

、

MddObserver

和

DdlObserver

。每个主体只能注册其中一个观察者界面，但

通知框

可以实现这三种模式。

将观察者与GoF模式进行比较 在GoF观察者中，

notify（）

在抽象的

Subject

中实现：调用所有观察者的

update（）

函数，由他们决定对象更新通知是否相关。这样，观察者就不必知道关于观察者的任何具体信息

第一个潜在的设计问题 如果您让

受试者

决定通知哪个

观察者

，受试者可能需要了解有关观察者的其他详细信息。根据受试者在决策时需要了解观察者的哪些信息，这可能行，也可能不行：

• 如果具体的主体需要了解具体的观察者，那么设计将以一种不可取的方式增加耦合。事实上，这与实际情况相反，因为添加新类型的观察者需要调整具体的主体。维护噩梦就在眼前
• 如果具体的主体只需要知道抽象观察者的界面，那么您的设计就可以了。本着的精神，我建议将此模式与相结合，让

  notify（）

  具有通用性，并使其依赖于可根据具体主体而改变的抽象条件

第二个潜在的设计问题 似乎你的具体观察者需要知道主题的类型才能调用正确的更新函数。我不确定这是否真的是这样，但这是你的命名约定的印象，即

updatexx（）

，因为每个

XXX

只用于一个主题

如果是这样的话，

观察者

抽象将取决于

主题

的具体实现。这似乎不是一个好主意：具体类可能依赖于抽象类，但与开/关原则相反

UML建模问题 在UML图上，我建议不要使用从

Subject

到

Observer

的黑色合成菱形：

• 复合（黑钻石）意味着观察者完全属于主体（即，如果主体被删除，其观察者将无法生存）。我怀疑这里的情况是否如此
• 聚合（白钻石）的含义类似，但具有共享所有权（非排他性）。我不能排除这一点，但我认为在这里也没有令人信服的理由使用它
• 我推荐一个简单的（一对多）关联
• 如果将1的多重性保留在主体一侧，则观察者必须在其构造过程中进行注册。这是您打算实现的，还是应该是0..1

从具体观察者到所有具体主体的通航协会提出了以下问题：

• 具体观察者和抽象主题之间是否存在可导航的关联？（在本例中，为了准确起见，绘制与抽象类的关联）
• 或者在具体的观察者和每个人之间有三种可导航的关联