设计模式:调停者模式

调停者模式

一、引子
Mediator Pattern 中文译为“中介者模式”、“调停者模式”。其实都不是很好，由于现
实生活中的“中介”是要和客户打交道，而省去客户原本繁琐的手续，这一点和门面模式的
初衷很相像；而在Mediator Pattern 中Mediator 是不可见的。“调停”也不好，因为Mediator
在程序中存在的初衷仅仅是规范信息传递的方式。
因此叫做“传递器模式”仿佛更能体贴一些，但是本文还是称其为“调停者模式”。

二、定义与结构
GOF 给调停者模式下的定义是：用一个调停对象来封装一系列的对象交互。调停者使
各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
简单点来说，将原来两个直接引用或者依赖的对象拆开，在中间加入一个“调停”对象，使得
两头的对象分别和“调停”对象引用或者依赖。
当然并不是所有的对象都需要加入“调停”对象。如果对象之间的关系原本一目了然，调
停对象的加入便是“画蛇添足”。
来看下调停者模式的组成部分吧。
1) 抽象调停者（Mediator）角色：抽象调停者角色定义统一的接口用于各同事角色之间的
通信。
2) 具体调停者（Concrete Mediator）角色：具体调停者角色通过协调各同事角色实现协
作行为。为此它要知道并引用各个同事角色。
3) 同事（Colleague）角色：每一个同事角色都知道对应的具体调停者角色，而且与其他
的同事角色通信的时候，一定要通过调停者角色协作。
来自《设计模式》一书的类图：

由于调停者的行为与要使用的数据与具体业务紧密相关，抽象调停者角色提供一个能方
便很多对象使用的接口是不太现实的。所以抽象调停者角色往往是不存在的，或者只是一个
标示接口。如果有幸能够提炼出真正带有行为的抽象调停者角色，我想同事角色对具体调停
者角色的选择也是策略的一种应用。
呵呵，“恰到好处，过犹不及”。适合自己系统的便是最好的。

三、进一步讨论
是否还记得应用广泛的MVC 分为哪三层？模型层（Model）、表现层（View）还有控制
层（Control\Mediator）。控制层便是位于表现层与模型层之间的调停者。笼统地说MVC 也
算是调停者模式在框架设计中的一个应用。
由于调停者模式在定义上比较松散，在结构上和观察者模式、命令模式十分相像；而应
用目的又与结构模式“门面模式”有些相似。
在结构上，调停者模式与观察者模式、命令模式都添加了中间对象——只是调停者去掉
了后两者在行为上的方向。因此调停者的应用可以仿照后两者的例子去写。但是观察者模式、
命令模式中的观察者、命令都是被客户所知的，具体哪个观察者、命令的应用都是由客户来
指定的；而大多调停者角色对于客户程序却是透明的。当然造成这种区别的原因是由于它们
要达到的目的不同。
从目的上看，调停者模式与观察者模式、命令模式便没有了任何关系，倒是与前面讲过
的门面模式有些相似。
但是门面模式是介于客户程序与子系统之间的，而调停者模式是介于子系统与子系统之
间的。这也注定了它们有很大的区别：门面模式是将原有的复杂逻辑提取到一个统一的接口，
简化客户对逻辑的使用。它是被客户所感知的，而原有的复杂逻辑则被隐藏了起来。而调停
者模式的加入并没有改变客户原有的使用习惯，它是隐藏在原有逻辑后面的，使得代码逻辑
更加清晰可用。
前面已经陆陆续续的将调停者模式的特点写了出来。这里再总结一下。使用调停者模式
最大的好处就是将同事角色解耦。这带来了一系列的系统结构改善：提高了原有系统的可读
性、简化原有系统的通信协议——将原有的多对多变为一对多、提高了代码的可复用性……
呵呵，但是调停者角色集中了太多的责任，所有有关的同事对象都要由它来控制。这不
由得让我想起了简单工厂模式，但是由于调停者模式的特殊性——与业务逻辑密切相关，不
能采用类似工厂方法模式的解决方法。因此建议在使用调停者模式的时候注意控制调停者角
色的大小。
讨论了这么多关于调停者模式的特点。可以总结出调停者模式的使用时机：一组对象以
定义良好但是复杂的方式进行通信，产生了混乱的依赖关系，也导致对象难以复用。

四、总结
调停者模式的使用有着分层设计的雏形。分层是开发人员分离复杂系统时最常用、最普
通的技术。J2EE 的三层结构估计大家都耳熟能详。而调停者模式的作用便是将关系错乱复
杂、层次不清晰的对象群分割成两层或者三层。
调停者模式很容易在系统中应用，也很容易在系统中误用。当系统出现了“多对多”交

互复杂的对象群，不要急于使用调停者模式，而要先反思你的系统在设计上是不是合理。