中介者模式

观察者与订阅/发布模式的区别

1.观察者模式中观察者必须对主题进行订阅后，才能收到主题的事件。

2.订阅/发布模式旨在为观察者和发布者之间构建一个渠道，解耦观察者与订阅者之间相互依赖的关系。此事件系统允许代码定义特定于应用程序的事件，并且可以传递用户需要的自定义参数。

这种与观察者不同的模式，允许任何的订阅者可以用一种合适的方式去实现一个事件处理程序，来注册感兴趣的事件并在发布者发布时候获得消息的接收。

订阅/发布者模式与中介者模式的差异

两方面，一方面是事件，一方面是第三方对象

事件

在订阅/发布者模式中，模式根据事件名处理逻辑
中介者模式虽然使用事件，但仅仅是为了方便，它不一定要使用事件

第三方对象角度看

在订阅/发布者模式中自己扮演事件系统中的中枢，只是为了方便事件从未知的数据源传递到未知的事件处理程序，所有的业务流程都放到了事件发布和事件处理中。

在中介者模式中，虽然业务流都汇聚到了中介者中，但中介者根据自己所知情况决定何时调用对象的方法、何时更新对象的属性。它封装了业务流以及对象之间的协作，使系统按着预期的方向前进。

订阅/发布者模式使用了一种“一劳永逸”的工作方式，触发了事件就不管其他了。而中介者模式使用事件作出决定的同时也会关心已知的输入和状态以便促进和协调一组参与者(对象)的行为。

什么时候用事件聚合模式什么时候用中介者模式

事件聚合模式

有太多的对象需要直接监听或者完全无关的几个对象。
或者两个对象有直接的关系，比如父子view时候的，子view可以给父view传播事件
间接的关系也好，例如想实现点击左边的菜单栏的一项菜单，右边显示相应的内容。

中介者模式

两个或者多个对象没有直接的练习并且业务逻辑或者工作流需要决定这些对象的交互和协调

向导的界面是个很好的例子,就像上例的“组织结构图”,有多个界面去帮助向导的工作流。与其通过相互引用紧耦合这些页面，不如引入中介者模式解耦他们的关联，达到一种更明确的工作流模型。

终结中从实现细节中提取工作流并且在更高的层次上创建一种更自然的抽象。以更快的方式向我们展示工作流是什么。我们不再需要深入到工作流中每个视图的细节处中去探寻工作流实际上是什么样的。

优点 & 缺点

中介者模式最大的好处是它减少了系统中的对象或组件之间的通信信道，使对象/组件之间从多到多的关系优化到多对一的关系
在现有的解耦水平上增加新的观察者和发布者是容易的。

也许使用这种模式的最大缺点是它可以引入一个单一的故障点，在模块之间放置中介者也许会导致性能下降，因为模块间总是间接通信。由于松散耦合的本质，很难确定系统是如何通过只看广播来反应的。
也就是说，提醒我们我们自己解耦系统还有许多其他的好处——如果我们的模块之间互相直接沟通，相互调用，那么一个模块的改变将产生多米诺骨牌效应，影响到我们应用的其他部分，这个解耦系统较少关注的。

中介者模式 Vs 外观模式

我们将简要的提及下外观模式，作为参考的目的。一些开发者可能会觉得，外观模式与中介者模式之间有很多相似的地方。它们既抽象了现有模块的功能，又存在一些细微的差异。

中介者模式使一些模块的交流在它的集中控制之下，在某种意义上说是多向的。门面模式仅仅是对模块或者系统简单的定义了一个接口，但是并没有添加额外的功能。系统中其他模块并不直接了解门面模式的概念，可以认为是单向的。