1. 动机
- 在软件构建过程中，经常会出现多个对象互相关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的变更，这种直接的引用关系将面临不断的变化。
- 在这种情况下，我们可以使用一个“中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好的抵御变化。
举例：
界面有非常多的控件，这个时候大家通常希望，更改界面控件状态的的时候，对应背后可能有你的数据DataModel也希望跟着更改，同样的，如果你的DataModel更改的时候，你的界面也希望跟着更改。这种情况，就会导致双向的直接依赖关系，即界面元素需要引用DadaModel对象，数据对象可能也需要引用界面元素，这种肯定不合适，比如后面更换界面元素的话，那修改代价非常高。
2. 模式定义
用一个中介对象来封装（封装变化）一些列的对象交互。中介者使个对象不需要显式的互相引用（编译时依赖 -> 运行时依赖），从而使其耦合松散（管理变化），而且可以独立地改变他们之间的交互。
----《设计模式》GOF
3. 结构
上图中，本来ConcreteColleague1和ConcreteColleague2是直接依赖的，转成了上图的Colleague之间没有依赖关系，他们都去依赖Mediator，反过来Mediator内部依赖Colleague，所以Colleague和Mediartor直接是双向依赖。
但是现实中，ConcreteColleague1和ConcreteColleague2常常不是上面图的继承关系的，比如前面的组件和DataBase。
更易理解的图表示：
比如上面的依赖关系，其中数字表示的节点都是上面结构图中的Colleague，修改为：
有网友表示，M有点像“物业”，很形象！！
该模式和Facade模式有点异曲同工，都是提出新的类进行隔离，Facade解决的是系统外和系统内的隔离，中介者是解决系统内各个类的隔离。
4. 要点总结
- 将多个对象间复杂的关联关系解耦，Mediator模式将多个对象间的控制逻辑进行集中管理，变“多个对象互相关联”为“多个对象和一个中介者关联”，简化了系统的维护，抵御了可能的变化。
- 随着控制逻辑的复杂化，Mediator具体对象的实现可能相当复杂。这时候可对Mediator对象进行给你分解处理
- Facade模式是解耦系统间（单向）的对象关联关系；Mediator模式是解耦系统内各个对象之间（双向）的关联关系。