中介模式与发布/订阅

Question

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

似乎至少在概念上，这两者是非常密切相关的。如果我冒险猜测，我会说发布/订阅方法是中介模式的一个子集（因为中介不一定需要以发布/订阅方式使用，但后者似乎需要一种中介宾语）。那附近有什么地方吗？

Answer 1

我如何描述不同之处在于，在调解器中，您可能会关心最终应用程序是否收到消息。所以你用它来保证谁收到消息。而对于pub / sub，您只需发布您的消息。如果有任何订阅者他们会得到它但你不在乎。

Answer 2

根据this page，发布 - 订阅模型是中介模式的实现。

修改

我应该注意，设计模式被称为“模式”正是因为每个实现之间都存在差异。它们不是一组法令形式的规范形式，因为它们是关于人们如何编写软件的观察的集合。因此，设计无法“严格”遵守设计模式。

Answer 3

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

实际上，在发布/订阅模式的实现中，您将至少拥有一个带有“publish”和“subscribe”方法的对象。 但是你可以拥有更多它们，因此组件之间的通信不是按照定义集中的。

在Mediator模式的实现中，您将拥有JUST ONE对象，其方法为“publish”和“subscribe”。因此，根据定义，沟通是“集中的”。

Answer 4

我认为一个主要的不同点是问题的背景。

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

1：“事件带来的变化有多大取决于一般背景？”

2：“听众应该多久改变一次？”

中介模式的经典案例最能说明这一点，即您拥有包含大量组件的复杂UI，并且每个组件的更新都对其他类似组件的状态具有复杂的相互依赖性。

虽然你可以用pub / sub模式解决这个问题;其中您的组件侦听事件并包含更新所需的逻辑，上下文对象（以及事件）携带所有必要的信息。这里的优点显然是适当地封装了与其自身内部组件有关的逻辑。缺点是如果这些组件经常发生变化，那么你必须在你引入的每个新组件中完全复制这个逻辑。

使用介体是从组件引入另一个层和进一步的摘要。这些组件变得更薄，因为它们只处理表示（UI外观），因此变得非常容易。我使用这种方法的唯一问题是，更新逻辑现在似乎溢出到其他组件，如果组件行为也要改变，系统的任何更新都需要更改组件和介体。

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

Answer 5

在GoF书中，发布/订阅称为观察者模式。中介者模式可以使用观察者模式来实现；但这不是实现调解器的唯一方法。本书在第278页对此进行了描述。

  

同事与调解员的交流。发生感兴趣的事件时，同事必须与调解员进行沟通。一种方法是使用观察者模式将中介程序实现为观察者。同事班充当主题，每当他们更改状态时就向中介发送通知。调解员通过将更改的影响传播给其他同事来做出回应。

     

另一种方法在Mediator中定义了一个专门的通知界面，该界面使同事之间的交流更加直接...当与Mediator进行交流时，同事会将自己作为参数进行传递，从而允许Mediator识别发送者。

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