设计模式（16） 中介者模式（简单入门 行为模式）

设计图和源代码请访问我的github：https://github.com/yangsheng20080808/DesignModel

From Now On，Let us begin Design Patterns。

中介者模式

你为什么需要中介者模式：

定义

• 用一个中介对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使其耦合松散，而且可以独立地改变它们之间的交互。 Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.

通用类图:

角色解说：

抽象中介者：定义好同事类对象到中介者对象的接口，用于各个同事类之间的通信。一般包括一个或几个抽象的事件方法，并由子类去实现。

中介者实现类：从抽象中介者继承而来，实现抽象中介者中定义的事件方法。从一个同事类接收消息，然后通过消息影响其他同时类。

同事类：如果一个对象会影响其他的对象，同时也会被其他对象影响，那么这两个对象称为同事类。在类图中，同事类只有一个，这其实是现实的省略，在实际应用中，同事类一般由多个组成，他们之间相互影响，相互依赖。同事类越多，关系越复杂。并且，同事类也可以表现为继承了同一个抽象类的一组实现组成。在中介者模式中，同事类之间必须通过中介者才能进行消息传递。

通用源码实现如下：

中介者模式的优点：

• 减少类间的依赖，把原有的一对多的依赖变成了一对一依赖，同事类只依赖中介者，减少了依赖，当然同时也降低了类间的耦合

• 使用中介者模式可以将对象间一对多的关联转变为一对一的关联，使对象间的关系易于理解和维护。

中介者模式的缺点：

• 中介者会膨胀得很大，而且逻辑复杂，原本N个对象直接的相互依赖关系转换为中介者和同事类的依赖关系，同事类越多，中介者的逻辑就越复杂。

中介者模式对比其他相识模式：

由于中介者模式在定义上比较松散，在结构上和观察者模式、命令模式十分相像；而应用目的又与结构模式“门面模式”有些相似。

从目的上看，中介者模式与观察者模式、命令模式便没有了任何关系，倒是与前面讲过的门面模式有些相似。

但是门面模式是介于客户程序与子系统之间的，而中介者模式是介于子系统与子系统之间的。这也注定了它们有很大的区别：门面模式是将原有的复杂逻辑提取到一个统一的接口，简化客户对逻辑的使用。它是被客户所感知的，而原有的复杂逻辑则被隐藏了起来。而中介者模式的加入并没有改变客户原有的使用习惯，它是隐藏在原有逻辑后面的，使得代码逻辑更加清晰可用。

前面已经陆陆续续的将中介者模式的特点写了出来。这里再总结一下。使用中介者模式最大的好处就是将同事角色解耦。这带来了一系列的系统结构改善：提高了原有系统的可读性、简化原有系统的通信协议——将原有的多对多变为一对多、提高了代码的可复用性……

呵呵，但是中介者角色集中了太多的责任，所有有关的同事对象都要由它来控制。这不由得让我想起了简单工厂模式，但是由于中介者模式的特殊性——与业务逻辑密切相关，不能采用类似工厂方法模式的解决方法。

中介者模式的使用场景：

滥用中介者模式，只会让事情变的更复杂

我们熟悉的MVC模式，其中的Controller就是中介者模式很好的实现。

中介者模式的注意事项：

因此建议在使用中介者模式的时候注意控制中介者角色的大小。

中介者模式的例子：

先看一个反例：


这里的A和B是直接耦合在一起的，以后我们要改A的时候会牵涉到所有与A关联的类，耦合度太高。

中介者模式的例子：
同事类：

抽象中介者类：

介者类：

客户端：

虽然代码比较长，但是还是比较容易理解的，其实就是把原来处理对象关系的代码重新封装到一个中介类中，通过这个中介类来处理对象间的关系。