中介者模式 vs 发布/订阅模式

Question

有人能指出这两者之间的主要区别吗？

至少在概念上，这两者似乎非常相似。如果我猜的话，我会说发布/订阅方法是中介者模式的子集（因为中介者不一定要以发布/订阅方式使用，但后者似乎需要一种中介对象）。这是否接近实际情况呢？

- Kristian D'Amato

Answer 1

我会这样描述它们的不同之处：在中介者模式中，你可能关心最终应用程序是否接收到消息。因此，你使用这种方式来确保谁接收了消息。而在发布/订阅模式中，你只需发布你的消息。如果有任何订阅者，他们将会得到它，但你并不关心。

- spinon

Answer 2

根据这个页面的介绍，发布-订阅模型是中介者模式的一种实现方式。

编辑

需要注意的是，设计模式之所以被称为“模式”，正是因为每个实现都会有所不同。它们不是一组被规定的、权威的形式，而是对人们如何编写软件的观察集合。因此，设计并没有严格遵循设计模式的方法。

- Cogwheel

Answer 3

实现可能是相同的，但从逻辑上讲它们是不同的（差异很简单，但难以看出）。我将在下面以简单的方式解释。

实际上，在发布/订阅模式的实现中，您至少会有一个具有“发布”和“订阅”方法的对象。但是您也可以拥有更多的对象，因此组件之间的通信并不是根据定义集中化的。

在中介者模式的实现中，您只会有一个具有“发布”和“订阅”方法的对象。因此，按定义，通信是“集中”的。

- Gabriel Nosso

Answer 4

在GoF的书中，发布/订阅被称为观察者模式。中介者模式可以使用观察者模式来实现，但这不是实现中介者的唯一方法。该书在第278页描述了这一点。

同事-中介者通信。当感兴趣的事件发生时，同事们必须与中介者进行通信。一种方法是使用观察者模式将中介者实现为观察者。同事类充当主题，每当它们更改状态时向中介者发送通知。中介者通过将更改的影响传播到其他同事来做出响应。

另一种方法是在中介者中定义一个专门的通知接口，使同事们在通信时更加直接...当与中介者通信时，同事会将自身作为参数传递，使中介者能够识别发送者。

请注意，即使将中介者实现为观察者，它也仅被描述为在其同事之间进行通信，而一般情况下，观察者可能还会与其他对象进行通信。

- jaco0646

Answer 5

我认为一个主要的区别点是问题的上下文。

虽然一个问题可以用任何一种模式来解决，但真正的关注点是：

1：“事件带来的变化程度取决于总体上下文？”

2：“听众预计会有多频繁更改？”

中介者模式最好地说明了这个经典案例，其中您拥有具有许多组件的复杂UI，并且每个组件的更新都对其他类似组件的状态具有复杂的相互依赖性。

虽然您可以使用发布/订阅模式来解决此问题；其中您的组件侦听事件并包含必要的逻辑以进行更新，但上下文对象（连同事件）携带所有必要的信息。 这里的优点显然是在组件内部正确封装与组件相关的逻辑。 缺点是，如果这些组件经常需要更改，则必须在每个新组件中完全复制此逻辑。

使用中介者是引入另一层并进一步抽象化组件。这些组件变得更薄，因为它们只处理表示（UI外观和感觉），因此变得非常容易更改。我对这种方法唯一的问题是更新逻辑现在似乎会泄漏到其他组件，并且如果组件行为也要更改，则系统的任何更新都需要更改组件和中介者。

对我来说，这是我们需要解决的主要困境/权衡。如果我理解有误，请纠正我。

- redzedi