关于中介者模式

在中译版《JS设计模式》中，中介者模式的简单实现用的是和publish/subscribe差不多的代码，这就造成了一个疑惑：

中介者模式和观察者模式看起来差不多呀？

其实只是因为，在简单的情境中它们可以使用相似的实现而已。

《Learning JavaScript Design Patterns》这本书，当初出版之后就有人提出书中mediator的示例根本就是pub/sub模式，作者随后表示电子书中的示例已经更改。见帖子：

然而我买的《模式》是16年第n次印刷。。。，依然是当年那版的示例。

我：???

-------------------分割线--------------

其实在软件的定义中，中介者和观察者完全是动机不同的两种设计模式：

观察者模式针对的场景是：系统中其他对象需要根据某一对象的状态变化做出调整（回调函数）。

我们可以简单地给目标添加一个观察者列表，也可以通过pub/sub代理观察者的回调以实现解耦。

而中介者是为了处理系统中，当有多个对象且这些对象需要相互引用（通信）时，为了降低系统复杂度，避免各部分的过度耦合，引入一个中介对象，让原本多对多通信变成多对一通信（此时，系统中对象之间网状的通信关系变成以中介者为通信中心的星状关系）。

中介者对外暴露统一的交互接口，内部封装了具体对象间的交互逻辑。对象之间不再直接与其他对象通信，而是统一向中介者发出信号，让中介者根据信号决定何时、对哪个目标、执行哪段代码。

网上有很多对中介者模式的帖子，许多是java实现的，作为了解中介者模式的途径也是够用了。

至于在js层面，作者也表示：观察者和中介者可能有时候实现上看起来很类似：

1.他们都经常使用事件回调来响应发布者的信号

2.二者的实现也常常引入新的对象来代理“通信”

其实：

pub/sub模式本身的设计就是为了处理事件，而中介者并不一定要使用事件机制，只是采用事件机制往往会很方便。

二者虽然都引入了第三方对象，但是在观察者模式中，第三方对象只是简单地存储回调，并在条件触发时执行。业务逻辑和工作流程是在其他对象中的。

而中介者模式则是把业务逻辑和工作流程封装在对象内部。

事实上，该书的电子版中，为了强调和pub/sub的区别，示例定义了一个对象，并在里面以事件监听的方式封装了工作流程代码，以实现对页面其他对象的的调度。由于在页面的生命周期中，事件是不定期触发的，事件触发后，中介者执行回调任务，实现“中转”站的角色。