有人能指出两者之间的主要区别吗?
似乎,至少在概念上,两者是非常密切相关的。如果我冒险猜测,我会说发布/订阅方法是中介模式的一个子集(因为中介不一定必须以发布/订阅方式使用,但后者似乎需要一种中介目的)。是不是离它很近?
有人能指出两者之间的主要区别吗?
似乎,至少在概念上,两者是非常密切相关的。如果我冒险猜测,我会说发布/订阅方法是中介模式的一个子集(因为中介不一定必须以发布/订阅方式使用,但后者似乎需要一种中介目的)。是不是离它很近?
我将如何描述不同之处在于,在调解器中,您可能关心最终应用程序是否收到消息。所以你用它来保证谁在接收消息。而使用 pub/sub,您只需发布您的消息。如果有任何订阅者,他们会得到它,但你不在乎。
根据这个页面,发布-订阅模型是中介者模式的一种实现。
编辑
我应该注意到,设计模式被称为“模式”正是因为每个实现之间都会存在差异。它们与其说是一套规定的、规范的形式,不如说是对人们如何编写软件的观察的集合。所以实际上没有任何方法可以让设计“严格”遵守设计模式。
实现可能相同,但逻辑上它们是不同的(区别很简单,但很难看出)。我将在下面以简单的方式解释它。
实际上,在发布/订阅模式的实现中,您将至少拥有一个带有“发布”和“订阅”方法的对象。但是您也可以拥有更多它们,因此组件之间的通信按照定义不是集中的。
在中介者模式的实现中,您将拥有一个带有“发布”和“订阅”方法的对象。因此,根据定义,通信是“中心化的”。
在 GoF 书中,发布/订阅被称为观察者模式。中介者模式可以使用观察者模式来实现;但这不是实现调解器的唯一方法。本书第 278 页对此进行了描述。
同事-调解员沟通。当感兴趣的事件发生时,同事必须与他们的调解员沟通。一种方法是使用观察者模式将中介者实现为观察者。同事类充当主题,每当它们改变状态时向中介发送通知。调解员通过将变更的影响传播给其他同事来做出回应。
另一种方法是在 Mediator 中定义一个专门的通知接口,让同事在沟通中更加直接……在与 mediator 通信时,同事将自己作为参数传递,允许 mediator 识别发送者。
请注意,即使将 Mediator 实现为 Observer,它也被描述为仅在其同事之间进行通信,而 Observer 通常也可能与其他对象进行通信。
我认为主要区别之一是问题的背景。
尽管任何一种模式都可以解决问题,但真正的问题是:
1:“事件带来多少变化取决于大环境?”
2:“听众期望多久更换一次?”
中介者模式的经典案例最能说明这一点,其中您有一个包含大量组件的复杂 UI,并且每个组件的更新都对其他类似组件的状态具有复杂的相互依赖性。
虽然你可以用 pub/sub 模式解决这个问题;其中您的组件侦听事件并包含更新所需的逻辑,上下文对象(连同事件)携带所有必要的信息。这里的优势显然是与组件本身相关的逻辑的适当封装。不利的一面是,如果这些组件应该经常更改,那么您必须在引入的每个新组件中完全复制此逻辑。
使用中介就是引入另一个层并从组件中进一步抽象。这些组件变得更薄,因为它们只处理表示(UI 外观和感觉),因此变得非常容易更改。这种方法的唯一问题是更新逻辑现在似乎溢出到其他组件,并且如果组件行为也要改变,系统的任何更新都需要更改组件和中介。
对我来说,这是我们需要解决的主要困境/权衡。如果我没有正确得到任何东西,请纠正我。