中介者模式有以下几部分组成:
抽象中介者(Mediator)角色:抽象中介者角色定义统一的接口用于各同事角色之间的通信。
具体中介者(Concrete Mediator)角色:具体中介者角色通过协调各同事角色实现协作行为,因此它必须依赖于各个同事角色。
同事(Colleague)角色:每一个同事角色都知道中介者角色,而且与其他的同事角色通信的时候,一定要通过中介者角色协作。每个同事类的行为分为两种:一种是同事本身的行为,比如改变对象本身的状态,处理自己的行为等等,这种方法叫做自发行为(Self-Method),与其他的同事类或中介者没有任何的依赖;第二种是是必须依赖中介者才能完成的行为,叫做依赖方法(Dep-Method)。
中介者模式的优点就是减少类间的依赖,把原有的一对多的依赖变成了一对一的依赖,同事类只依赖中介者,减少了依赖,当然也同时减低了类间的耦合。它的缺点呢就是中介者会膨胀的很大,而且逻辑会很复杂,因为所有的原本N 个对象直接的相互依赖关系转换为中介者和同事类的依赖关系,同事类越多,中介者的逻辑就复杂。
那在什么环境下才使用中介者模式呢?中介者模式适用于多个对象之间紧密耦合,耦合的标准可以这样来衡量:在类图中出现了蜘蛛网状结构,在这种情况下一定要考虑使用中介者模式,有利于把蜘蛛网梳理为一个星型结构,使原本复杂混乱关系变得清晰简单。
中介者模式是一个非常好的封装模式,也是一个很容易被滥用的模式,一个对象依赖几个对象是再正常不过的事情,但是纯理论家就会要求使用中介者模式来封装这种依赖关系,这是非常危险的信号,使用中介模式就必然会带来中介者的膨胀问题,这在一个项目中时很不恰当的,那到底在什么情况下使用中介者模式呢?大家可以在如下的情况下尝试使用中介者模式:
1、N 个对象之间产生了相互的依赖关系,其中N 大于2,注意是相互的依赖;
2、多个对象有依赖关系,但是依赖的行为尚不确定或者有发生改变的可能,在这种情况下一般建议采用中介者模式,降低变更引起的风险扩散;
3、产品开发。其中一个明显的例子就是MVC 框架,把这个应用到产品中,可以提升产品的性能和扩展性,但是作为项目开发就未必,项目是以交付投产为目标,而产品以稳定、高效、扩展为宗旨。