C++ 中介模式与发布/订阅

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

看来，至少在概念上，这两者是非常密切相关的。如果我冒昧猜测一下，我会说发布/订阅方法是中介模式的子集（因为中介不一定需要以发布/订阅方式使用，但后者似乎需要某种中介对象）。这离它很近吗？

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

编辑

---

我应该注意到，设计模式被称为“模式”，正是因为每个实现之间都会存在差异。与其说它们是一组规定的、规范的形式，不如说它们是关于人们如何编写软件的观察结果的集合。因此，实际上没有任何方法可以让设计“严格”遵守设计模式。

我将如何描述这种差异，在mediator中，您可能关心最终应用程序是否接收到消息。所以你用它来保证谁在接收信息。而使用pub/sub，您只需发布消息。如果有订户，他们会得到，但你不在乎。

我认为一个主要区别是问题的背景

尽管问题可以通过任何一种模式解决，但真正的问题是：

1：“这些事件会带来多少变化取决于总体环境？”

2：“预计听众多久更换一次？”

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

尽管您可以使用pub/sub模式解决这个问题；组件侦听事件并包含更新所需的逻辑时，上下文对象（以及事件）携带所有必要的信息。这里的优点显然是适当封装了与组件本身相关的逻辑。缺点是，如果这些组件应该经常更改，那么您必须在引入的每个新组件中完全复制此逻辑

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

---

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

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

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

---

在中介模式的实现中，只有一个对象具有“publish”和“subscribe”方法。因此，根据定义，通信是“集中的”。

在GoF书中，发布/订阅被称为观察者模式。中介模式可以使用观察者模式实现；但这并不是实现调解人的唯一途径。这本书在第278页描述了这一点

同事-调解人沟通。当发生感兴趣的事件时，同事必须与其调解人进行沟通。一种方法是使用观察者模式将中介体作为观察者实现。同事类充当主题，在状态发生变化时向中介发送通知。调解人通过向其他同事宣传变化的影响来做出回应

另一种方法是在Mediator中定义一个专门的通知接口，让同事在交流中更加直接。。。在与调解员沟通时，同事将自己作为一个论点传递，从而使调解员能够识别发送者

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