设计模式 -- 中介者模式 (Mediator Pattern)

---

定义：用一个中介对象封装一系列的对象交互，中介者使各个对象不需要显示地相互作用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

中介者模式也叫调停者模式，它的通用类图如下：类图中的Colleague同事类只有一个，现实中不止一个，这里采用了省略的方式

中介者模式.png

Mediator 抽象中介者角色：定义统一的接口，用于各同事角色之间的通信。

ConcreteMediator 具体中介者角色：通过协调同事角色实现协作行为，必须依赖于各个同事角色。

Colleague 同事角色：如果一个对象会影响其他的对象，并且也会被其他对象影响，那么这两个对象称之为同事类。每个同事都知道中介者的存在，并且必须通过这个中介者进行相互通信。

每个同事类的行为分为两种：①同事本身的行为，比如改变对象本身的状态，处理自己的行为等，这种行为叫做自发行为，与其他同事类和中介者没有任何依赖 ②必须通过中介者才能完成的行为，这种叫做依赖行为

中介者模式通用代码：
Mediator 抽象中介者角色 代码：

public abstract class Mediator {
    //定义同事类，并通过getter/setter方法将同事类注入进来
    //在这里我们注入的是同事类的实现类，为什么不使用抽象类注入呢？
    //因为没有存在每个同事类必须都完成的业务方法，若存在就使用抽象类注入，做到依赖倒置
   protected ConcreteMediator1 c1; 
   protected ConcreteMediator2 c2;
   
   public ConcreteMediator1 getC1() {
      return c1;
   }
   
   public void setC1(ConcreteMediator1 c1) {
      this.c1 = c1;
   }
   
   public ConcreteMediator2 getC2() {
      return c2;
   }
   
   public void setC2(ConcreteMediator2 c2) {
      this.c2 = c2;
   }
   
   public abstract void doSomething1(); //中介者模式的业务逻辑
   public abstract void doSomething2(); //中介者模式的业务逻辑
}

具体的中介者一般只有一个：ConcreteMediator

public class ConcreteMediator extends Mediator {
   @Override
   public void doSomething1() {
      //调用同事类的方法，只要是public的方法均可调用
      super.c1.selfMethod1(); 
      super.c2.selfMethod2();
   }
   
   @Override
   public void doSomething2() {
      super.c1.selfMethod1();
      super.c2.selfMethod2();
   }
}

doSomething1与doSomething2 都是比较复杂的业务逻辑，为同事类服务，其实现是依赖各个同事类来完成的。

同事类代码：

public  abstract class Colleague {
   protected Mediator mediator;
   public Colleague(Mediator mediator) {
      this.mediator = mediator;
   }
}

具体的同事类实现：

public class ConcreteColleague1 extends Colleague {
   //通过构造函数传递中介者
   public ConcreteColleague1(Mediator mediator) {
      super(mediator);
   }
   //自由方法
   public void selfMethod1(){
      //处理自己的业务逻辑
   }
   //依赖方法
   public void  depMethod1(){
      //处理自己的业务逻辑
      //自己不能处理的业务逻辑，委托给中介者完成
      super.mediator.doSomething1();
   }
}

public class ConcreteColleague2 extends Colleague {
   //通过构造函数传递中介者
   public ConcreteColleague2(Mediator mediator) {
      super(mediator);
   }
   //自由方法
   public void selfMethod2(){
      //处理自己的业务逻辑
   }
   //依赖方法
   public void  depMethod2(){
      //处理自己的业务逻辑
      //自己不能处理的业务逻辑，委托给中介者完成
      super.mediator.doSomething2();
   }
}

在这里使用构造函数注入中介者，而在中介者中使用getter/setter方法将同事类注入的原因是：同事类中必须有中介者，而中介者却可以只有部分同事类。

中介者模式的优点：
减少类间的依赖，把原来的一对多的依赖变成一对一的依赖，同事类只依赖中介者，减少耦合。
在这里使用图来说明
（1）蜘蛛网结构示意图

蜘蛛网结构示意图.png

在这种结构中，只要有一个对象产生变化，那么其他的跟它相关联的对象均需要修改，这显然不符合迪米特法则，类之间过度耦合，不利于类的复用，系统也不稳定。那么将结构优化，使用中介者模式的情况如下图所示

（2）中介者模式结构图（星型网络拓扑）

星型网络拓扑.png

优化后的结构中，每个对象的改变都只会影响到自己，不会对其他的对象以及中介者产生影响，这样减少了系统的耦合度，提高每个类的复用，减少依赖。

中介模式的缺点：
当同事类越多时（代表同事类逻辑越复杂），中介者的逻辑也会随之复杂，这样导致中介者越发的膨胀臃肿，因此需要考虑合理划分中介者与同事类的关系。

中介者模式的使用场景
根据上面优缺点我们可以看出，当一个项目中的类对象关系出现蜘蛛网结构时，就需要考虑引入中介者模式，这样才能更好的梳理类之间的关系。但是并不能因为几个简单的对象依赖关系，就随便引入中介者模式，这样会带来逻辑上的复杂性，因此需要三思而行。