WHAT

中介者模式(Mediator Pattern)也叫调停者模式

一个对象要和N多个对象交流,就想对象之间的战争,很混乱。需要加入一个中心,所有的类都和中心交流,中心说怎么处理就怎么处理。

定义

Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.

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

类图

Mediator - 抽象中介者角色

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

Concrete Mediator - 具体中介者角色

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

Colleague - 同事角色

每一个同事角色都知道中介者角色,与其他同事角色通信时,一定要通过中介者角色协作。

每个同事的行为分为两种:

  • 同事本身的行为
    • 改变对象本身的转台,处理自己的行为等
    • 自发行为 - Self-Method, 与其他的同事类或中介者没有任何的依赖
  • 必须依赖中介者才能完成的行为
    • 依赖方法- Dep-Method

源码

抽象中介者

public abstract class Mediator{
  // 定义同事类
  protected ConcreteColleague1 c1;
  protected COncreteColleague2 c2;
  //通过Getter、setting方法把同事类注入进来
  public ConcreteColleague getC1(){
    return c1;
  }
  public void setC1(ConcreteColleague1 c1)[
    this.c1 = c1;
   }
  public ConcreteColleague2 getC2(){
    return c2;
  }
  public void setC2(ConcreteColleague2 c2){
    this.c2 = c2;
  }
    
  // 中介者模式的业务逻辑
    public abstract void doSomething1();
    public abstract void doSomething2();
}
  • 只定义了同事类的注入,为什么使用同事实现类注入而不是抽象类注入呢?

    因为同事类虽然有抽象,但是没有每个同事类必须要完成的业务方法,如果每个同事类都有相同的方法,比如execute、handler等,可以注入抽象类,做到依赖倒置。

通用中介者

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

中介者所具有的方法doSomething1doSomething2都是比较复杂的业务逻辑,为同事类服务,其实现是依赖各个同事类来完成。

抽象同事类

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);
  }
  // 自由方法self-method
  public void selfMethod1(){
    // 处理自己的业务逻辑
  }
  // 依赖方法 dep-method
  public void depMethod1(){
    // 处理自己的业务逻辑
    //不能处理的业务逻辑,委托给中介者处理
    super.mediator.doSomething1();
  }
}

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

WHY

优点

  • 减少类间的依赖
    • 原有的一对多的依赖变成了一对一的依赖,同事类只依赖中介者,减少了依赖,同事也降低了类间的耦合。

缺点

  • 中介者会膨胀得很大,而且逻辑复杂
    • 原本N个独享直接的相互依赖转换为中介者和同事类的依赖关系,同事类越多,中介者的逻辑会越复杂

HOW

使用场景

中介者模式简单,但不容易使用,很容易误用。

类之间的依赖关系是必然存在的,一个类一拉多个类的情况也是存在的,存在即合理。

只要有多个一栏关系就考虑使用中介者模式呢?-- 答案是否定的。

中介者模式适用于多个对象之间紧密耦合的情况,紧密耦合的标准是:在类图中出现了蜘蛛网状结构。这种情况下一定要考虑使用中介者模式,有利于吧蜘蛛网梳理为星型结构,使原本复杂混乱的关系变得清晰简单。

实际应用

机场调度中心

同事类 - 飞机

中介者 - 调度中心

飞机寻味调度中心是否可以降落,调度中心查看其它飞机后,通知飞机降落。由调度中心把控调度逻辑

MVC框架

MVC框架汇总,C(Controller)是一个中介者,叫做前端控制器(Front Controller),作用是把M(Model,业务逻辑)和V(View,视图)隔离开,协调M和V协同工作,把M运行的结果和V代表的视图融合成一个前端可以展示的页面,减少M和V的依赖关系。

媒体网关

使用MSN发送消息,有中介者(MSN服务器)接受发送的消息,查找被发送对象,发送消息,并通知发送对象发送成功。

中介者负责协调两个客户端的信息交流

中介服务

显示的中介服务,租房中介、出国中介等

最佳实践

很少用到接口或者抽象类,这与依赖倒置原则是冲突的,为什么呢?

  • 是同事类而不是兄弟类(有相同的血缘)。这些类之间是协作关系,完成不同的任务,处理不同的业务,所以不能在抽象类或接口中严格定义同事类必须具有的方法
  • 在一个项目中,中介者模式可能被多个模块采用,每个中介者所围绕的同事类各不相同,不能抽象出一个具有共性的中介者。一个中介者抽象类一般只有一个实现者,除非逻辑非常复杂才会出现终结者的情况
  • 综上,对于中介者模式来说,抽象没有太多的必要。

中介者模式是一个非常好的封装模式,也是一个很容易被滥用的模式。

如下情况可以尝试使用中介者模式:

  • N个对象之间产生了相互的依赖关系(N>2)
  • 多个对象有依赖关系,但是依赖的行为尚不确定或者有可能发生改变的可能,在这种情况下一般建议采用中介者模式,降低变更引起的风险扩散。
  • 产品开发。产品已稳定、高效、扩展为宗旨,项目则以交付投产为目标,项目不一定适用。

《设计模式之禅》第十四章 中介者模式