中介者模式

中介者模式有以下几部分组成：
抽象中介者（Mediator）角色：抽象中介者角色定义统一的接口用于各同事角色之间的通信。
具体中介者（Concrete Mediator）角色：具体中介者角色通过协调各同事角色实现协作行为，因此它必须依赖于各个同事角色。
同事（Colleague）角色：每一个同事角色都知道中介者角色，而且与其他的同事角色通信的时候，一定要通过中介者角色协作。每个同事类的行为分为两种：一种是同事本身的行为，比如改变对象本身的状态，处理自己的行为等等，这种方法叫做自发行为(Self-Method)，与其他的同事类或中介者没有任何的依赖；第二种是是必须依赖中介者才能完成的行为，叫做依赖方法（Dep-Method）。

 

中介者模式的优点就是减少类间的依赖，把原有的一对多的依赖变成了一对一的依赖，同事类只依赖中介者，减少了依赖，当然也同时减低了类间的耦合。它的缺点呢就是中介者会膨胀的很大，而且逻辑会很复杂，因为所有的原本N 个对象直接的相互依赖关系转换为中介者和同事类的依赖关系，同事类越多，中介者的逻辑就复杂。

 

那在什么环境下才使用中介者模式呢？中介者模式适用于多个对象之间紧密耦合，耦合的标准可以这样来衡量：在类图中出现了蜘蛛网状结构，在这种情况下一定要考虑使用中介者模式，有利于把蜘蛛网梳理为一个星型结构，使原本复杂混乱关系变得清晰简单。

 

中介者模式是一个非常好的封装模式，也是一个很容易被滥用的模式，一个对象依赖几个对象是再正常不过的事情，但是纯理论家就会要求使用中介者模式来封装这种依赖关系，这是非常危险的信号，使用中介模式就必然会带来中介者的膨胀问题，这在一个项目中时很不恰当的，那到底在什么情况下使用中介者模式呢？大家可以在如下的情况下尝试使用中介者模式：
1、N 个对象之间产生了相互的依赖关系，其中N 大于2，注意是相互的依赖；
2、多个对象有依赖关系，但是依赖的行为尚不确定或者有发生改变的可能，在这种情况下一般建议采用中介者模式，降低变更引起的风险扩散；
3、产品开发。其中一个明显的例子就是MVC 框架，把这个应用到产品中，可以提升产品的性能和扩展性，但是作为项目开发就未必，项目是以交付投产为目标，而产品以稳定、高效、扩展为宗旨。