Java设计模式之中介者模式

一、引子

中介在现实糊口中并不生疏，满大街的衡宇中介、良莠不齐的出国中介……。它们的存在是因为它们能给我们的糊口带来一些便利：租房、买房用不着各个小区里瞎转；出国留学也不消不知所措。

中介者模式在措施设计中也起到了雷同的浸染。

二、界说与布局

GOF给中介者模式下的界说是：用一其中介工具来封装一系列的工具交互。中介者使各工具不需要显式地彼此引用，从而使其耦合松散，并且可以独立地改变它们之间的交互。简朴点来说，将本来两个直接引用可能依赖的工具拆开，在中间插手一个“中介”工具，使得两端的工具别离和“中介”工具引用可能依赖。

虽然并不是所有的工具都需要插手“中介”工具。假如工具之间的干系原本一目了然，中介工具的插手即是“多此一举”。

来看下中介者模式的构成部门吧。

1) 抽象中介者（Mediator）脚色：抽象中介者脚色界说统一的接口用于各同事脚色之间的通信。

2) 详细中介者（Concrete Mediator）脚色：详细中介者脚色通过协调各同事脚色实现协作行为。为此它要知道并引用各个同事脚色。

3) 同事（Colleague）脚色：每一个同事脚色都知道对应的详细中介者脚色，并且与其他的同事脚色通信的时候，必然要通过中介者脚色协作。

来自《设计模式》一书的类图：

由于中介者的行为与要利用的数据与详细业务细密相关，抽象中介者脚色提供一个能利便许多工具利用的接口是不太现实的。所以抽象中介者脚色往往是不存在的，可能只是一个标示接口。假如有幸可以或许提炼出真正带有行为的抽象中介者脚色，我想同事脚色对详细中介者脚色的选择也是计策的一种应用。

“恰到长处，矫枉过正”。适合本身系统的即是最好的。

三、进一步接头

是否还记得应用遍及的MVC分为哪三层？模子层（Model）、表示层（View）尚有节制层（Control\Mediator）。节制层即是位于表示层与模子层之间的中介者。笼统地说MVC也算是中介者模式在框架设计中的一个应用。

由于中介者模式在界说上较量松散，在布局上和调查者模式、呼吁模式十分相像；而应用目标又与布局模式“门面模式”有些相似。

在布局上，中介者模式与调查者模式、呼吁模式都添加了中间工具——只是中介者去掉了后两者在行为上的偏向。因此中介者的应用可以模拟后两者的例子去写。可是调查者模式、呼吁模式中的调查者、呼吁都是被客户所知的，详细哪个调查者、呼吁的应用都是由客户来指定的；而大多中介者脚色对付客户措施却是透明的。虽然造成这种区此外原因是由于它们要到达的目标差异。

从目标上看，中介者模式与调查者模式、呼吁模式便没有了任何关系，倒是与前面讲过的门面模式有些相似。

可是门面模式是介于客户措施与子系统之间的，而中介者模式是介于子系统与子系统之间的。这也注定了它们有很大的区别：门面模式是将原有的巨大逻辑提取到一个统一的接口，简化客户对逻辑的利用。它是被客户所感知的，而原有的巨大逻辑则被埋没了起来。而中介者模式的插手并没有改变客户原有的利用习惯，它是埋没在原有逻辑后头的，使得代码逻辑越发清晰可用。

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

可是中介者脚色会合了太多的责任，所有有关的同事工具都要由它来节制。这禁不住让我想起了简朴工场模式，可是由于中介者模式的非凡性——与业务逻辑密切相关，不能回收雷同工场要领模式的办理要领。因此发起在利用中介者模式的时候留意节制中介者脚色的巨细。

接头了这么多关于中介者模式的特点。可以总结出中介者模式的利用机缘：一组工具以界说精采可是巨大的方法举办通信，发生了杂乱的依赖干系，也导致工具难以复用。

四、总结

中介者模式很容易在系统中应用，也很容易在系统中误用。当系统呈现了“多对多”交互巨大的工具群，不要急于利用中介者模式，而要先反思你的系统在设计上是不是公道。