背景
最近写博客的时间非常少，天天加班，项目要上线，结果关键时候人都走了，只剩下我一个，说实话，我居然从Linux部署到C++ TCP服务器、到Web服务器、页面编写走通了！！只有移动客户端没有去涉及。不说了，这篇博客也是加班时编写的，继续努力中，希望坚持把《大话设计模式》在这个礼拜看完。
1、使用意图
把一系列对象的交互交付与中介者处理，那么可以耦合松散，使每一个对象都独立变化。
2、生活实例
QQ群聊天，所有人都不需要知道对方的信息，只要一发言，QQ群这个中介就会把信息发送到所有的群成员。
3、Java 例子（框架、JDK 、JEE）
《大话设计模式》的意思是说Form窗体中组件之间的通信是一个典型的中介者模式，这样理解，组件与组件之间不需要知道对方的存在关系，只要在事件监听处进行通知即可。我不知道是否理解透彻，总之觉得不是很对，因为事件监听其实也是在事件处理当中去通知另一个组件，组件与组件之间还是直接通信了，那就应该不是中介者模式。
4、模式类图
Mediator：中介者接口，声明各个同事之间相互对接的抽象方法 ，比如QQ群里的发言接口。
ConcreteMediator：具体的中介者实现对象。它需要维护所有的同事以及负责具体的协调各个同事对象的交互关系，也就是QQ群某个同事发言时应该如何通知其他同事 。
Colleague：同事类的定义，主要声明同事类的具体行为，同时，同事类中必须要要有中介者的引用，因为同事与同事之间没有任何联系，只有同事与中介者有直接联系。
ConcreteColleague：具体的同事类，实现自己的业务，需要与其他同事对象交互时，就通知中介对象，中介对象会负责后续的交互。换句话说，同事之间的交流都有中介者负责。
5、模式优点
中介者模式（Mediator）：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显示地相互引用，从而使其耦合松散，而且可以独立地改变他们之间的交互。
中介者模式很容易在系统中应用，也很容易在系统中误用。当系统中出现了”多对多“交互复杂的对象群时，不要急于使用中介者模式，而要先反思你的系统在设计上是否合理。
Mediator的出现减少了各个Colleague的耦合，使得可以独立地改变和复用各个Colleague类和Mediator。当然Colleague之间的耦合度降低是因为Mediator，所以Mediator是一个经常需要维护的类；
由于把对象如何协作进行了抽象，将中介者作为一个独立的概念并将其封装在一个对象中，这样关注的对象就从对象各自本身的行为转移到他们之间的交互上来，也就是站在一个更宏观的角度去看待系统。
也是由于ConcreteMediator 控制了集中化，于是就把交互复杂性变为了中介者的复杂性，这就使得中介者变得比任何一个ConcreteColleague都复杂。
中介者模式一般应用于一组对象已定义良好但是复杂的方式进行通信场合，以及想定制一个分布在多个类中的行为，而又不想生成太多的子类的场合。
6、与类似模式比较
尽管将一个系统分割成许多对象通常可以增加其可复用性，但是对象间相互连接的激增又会降低其可复用性。
大量的连接使得一个对象不可能在没有其他对象的支持下工作，系统表现为一个不可分割的整体，所以，对系统的行为进行任何较大的改动就十分困难。
中介者模式就是迪米特法则（最少知识原则）的体现。
相比观察者模式，你可能会发现二者之间挺多共同点，比如通知就是二者最大的共同点，但是二者也是截然不同的，比如观察者是主题发生变化就会立刻通知观察者做出改变，而中介者则是同事与同事之间的交流，交由中介进行通知。
名字上中介者模式和代理模式有着关系似的，实际上真的没什么关系。