定 义：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式的相互引用，从而使其耦合松散，而且可以独立地改变它们
之间的交互。
优 点：减少了类之间的相互依赖，把原有的一对多的依赖变成了一对一的依赖，同事类只依赖中间者，减少了依赖，当然也减少了类见耦合
缺 点：随着业务流程的复杂，中介者会膨胀很大，而且逻辑复杂
动 机：在软件构建过程中，经常会出现多个对象互相关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断的变化。在这种情况下，我们可使用一个“中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化。
Mediator模式的几个要点：
将多个对象间复杂的关联关系解耦，Mediator模式将多个对象间的控制逻辑进行集中管理，变“多个对象互相关联”为“多个对象和一个中介者关联”，简化了系统的维护，抵御了可能的变化。 随着控制逻辑的复杂化，Mediator具体对象的实现可能相当复杂。这时候可以对Mediator对象进行分解处理。 Façade模式是解耦系统外到系统内（单向）的对象关联关系；Mediator模式是解耦系统内各个对象之间（双向）的关联关系，先来看一看中介者模式的类图结构：
中介者模式应用场景特别多，举例子：一个公司又很多的部门，每个部门之间都会有沟通，这样会导致部门与部门之间的耦合度非常高，关系非常的复杂，而且有时候一件事情需要找多个部门去协调，那么这个时候引入一个中间机构，部门协调处理机构，部门之间的沟通只要找中介者即可。以我们现在公司来说，有销售部门，有资源管理部门，有运营部门，这三个部门之间经常会存在矛盾，一个问题经常在部门之间沟通来沟通去，最后还解决不了，现在引入由CEO亲自组建的中介者团队，专门负责部门之间的关系，这样这个部门之间打架的关系就少了！可见中介者的力量还是很强大的，虽然增加了人力成本，但是解决了企业流程复杂，使得工作效率更好！
再来看一个必须要有中介者模式介入的案例，机场调度中心，每一辆飞机的起飞和降落都必须得首先得到机场调度中的许可，而调度中心则根据复杂的情况来判断，包括从国家部门获得航空管制的信息，从而返回飞机是否可以起飞的指令，如果都让每架飞机自己沟通，那问题在那里？我的飞机要着陆了，我先要咨询有那条跑到是空的，如果没有空的，我要通知跑到上的飞机，赶紧让开，如果实在没位置了，是否要在空中等待一会，看那辆飞机要起飞，于是我要一个一个的咨询，想想这个难度有多复杂，要是将这个类间关系用UML描述出来，这是多么的恐怖的事情，蜘蛛网让每一个看到的人绝对崩溃，现在好了，有机场调度中心了，我们来看看机场时怎么在调度中心的配置之下如何正常运转吧。
再想想如果没有这个调度中心，飞机起飞和降落那是一件多么大的工程！另外，中介者模式在日常生活中到处可见，如二手房地产市场，房东要出售房子，而买主要购买房子，这个时候中介机构就显然非常的重要了。再想一想，现在中国男女比率越来越失去平衡，很多男性朋友找女朋友已经成了一个问题，甚至于有一些人开始寻找越南等不发达国家的女人来做老婆了，而现在男人要求也高，女人也是，这是一个相互的选择过程。不可能随便找一个人就娶了，那么久要到处去咨询女人，问：你愿意嫁给我吗？，女人回答：愿意或者不愿意，也许是神经病。问一次两次行，那么问多了，你不会觉得郁闷吗？那这样好了，我直接去婚姻介绍所，将个人要求说给介绍所听，介绍所帮忙查找符合条件的女人，然后去咨询，那么去咨询的人就不用很复杂了，得到的结果就是行还是不行，多简单省事。画一个UML图如下：
