调停者模式
引子
Mediator Pattern 中文译为“中介者模式”、“调停者模式”。其实都不是很好,由于现实生活中的“中介”是要和客户打交道,而省去客户原本繁琐的手续,这一点和门面模式的初衷很相像;而在 Mediator Pattern 中 Mediator 是不可见的。“调停”也不好,因为 Mediator在程序中存在的初衷仅仅是规范信息传递的方式。
因此叫做“传递器模式”仿佛更能体贴一些,但是本文还是称其为“调停者模式”。
定义与结构
GOF 给调停者模式下的定义是:用一个调停对象来封装一系列的对象交互。调停者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。简单点来说,将原来两个直接引用或者依赖的对象拆开,在中间加入一个“调停”对象,使得两头的对象分别和“调停”对象引用或者依赖。
当然并不是所有的对象都需要加入“调停”对象。如果对象之间的关系原本一目了然,调停对象的加入便是“画蛇添足”。
来看下调停者模式的组成部分吧。
-
抽象调停者(Mediator)角色:抽象调停者角色定义统一的接口用于各同事角色之间的通信。
-
具体调停者(Concrete Mediator)角色:具体调停者角色通过协调各同事角色实现协作行为。为此它要知道并引用各个同事角色。
-
同事(Colleague)角色:每一个同事角色都知道对应的具体调停者角色,而且与其他的同事角色通信的时候,一定要通过调停者角色协作。
来自《设计模式》一书的类图:
由于调停者的行为与要使用的数据与具体业务紧密相关,抽象调停者角色提供一个能方便很多对象使用的接口是不太现实的。所以抽象调停者角色往往是不存在的,或者只是一个标示接口。如果有幸能够提炼出真正带有行为的抽象调停者角色,我想同事角色对具体调停者角色的选择也是策略的一种应用。
进一步讨论
是否还记得应用广泛的 MVC 分为哪三层?模型层(Model)、表现层(View)还有控制层(Control\Mediator)。控制层便是位于表现层与模型层之间的调停者。笼统地说 MVC 也算是调停者模式在框架设计中的一个应用。
由于调停者模式在定义上比较松散,在结构上和观察者模式、命令模式十分相像;而应用目的又与结构模式“门面模式”有些相似。
在结构上,调停者模式与观察者模式、命令模式都添加了中间对象——只是调停者去掉了后两者在行为上的方向。因此调停者的应用可以仿照后两者的例子去写。但是观察者模式、命令模式中的观察者、命令都是被客户所知的,具体哪个观察者、命令的应用都是由客户来指定的;而大多调停者角色对于客户程序却是透明的。当然造成这种区别的原因是由于它们要达到的目的不同。
从目的上看,调停者模式与观察者模式、命令模式便没有了任何关系,倒是与前面讲过的门面模式有些相似。
但是门面模式是介于客户程序与子系统之间的,而调停者模式是介于子系统与子系统之间的。这也注定了它们有很大的区别:门面模式是将原有的复杂逻辑提取到一个统一的接口,简化客户对逻辑的使用。它是被客户所感知的,而原有的复杂逻辑则被隐藏了起来。而调停者模式的加入并没有改变客户原有的使用习惯,它是隐藏在原有逻辑后面的,使得代码逻辑更加清晰可用。
前面已经陆陆续续的将调停者模式的特点写了出来。这里再总结一下。使用调停者模式最大的好处就是将同事角色解耦。这带来了一系列的系统结构改善:提高了原有系统的可读性、简化原有系统的通信协议——将原有的多对多变为一对多、提高了代码的可复用性…
但是调停者角色集中了太多的责任,所有有关的同事对象都要由它来控制。这不由得让我想起了简单工厂模式,但是由于调停者模式的特殊性——与业务逻辑密切相关,不能采用类似工厂方法模式的解决方法。因此建议在使用调停者模式的时候注意控制调停者角色的大小。
讨论了这么多关于调停者模式的特点。可以总结出调停者模式的使用时机:一组对象以定义良好但是复杂的方式进行通信,产生了混乱的依赖关系,也导致对象难以复用。
总结
调停者模式的使用有着分层设计的雏形。分层是开发人员分离复杂系统时最常用、最普通的技术。J2EE 的三层结构估计大家都耳熟能详。而调停者模式的作用便是将关系错乱复杂、层次不清晰的对象群分割成两层或者三层。
调停者模式很容易在系统中应用,也很容易在系统中误用。当系统出现了“多对多”交互复杂的对象群,不要急于使用调停者模式,而要先反思你的系统在设计上是不是合理。