中介者模式(Mediator Pattern)

只有一个仲裁者

1.模式介绍

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

使用场景:

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

实际使用:

中介者模式也叫调停者模式，一个对象要与N个对象交流，就非常混乱。如果加入一个调度中心，所有的类都和中心交流，中心说怎么处理就怎么处理，这是不是非常方便。

机场调度中心

这是一个具体的中介者

MVC框架

MVC框架中，C（Controller）就是一个中介者，它的作用就是把M(Model,业务逻辑)和V(View,视图)隔离开，协同M和V工作，M运行结果和V代表的视图交互，减少M和V的依赖关系。MVC框架已经非常流行，这也是中介者模式的优点的一个体现。

中介服务

现在中介服务十分的多，比如租房中介，出国中介，这些都是中介模式的具体体现。比如，如果你要租房子，如果没有房屋中介，你就必须一个一个小区去找，还是和房东签约，检查家具，水电煤等等，如果有了中介，那你只需要知会中介你的要求，看完房子就直接签约，而找房子，与房东谈价格，检查家具，水电煤，网络电视等等，可以全部由中介帮你处理了，是不是十分的方便。

角色介绍

Mediator:抽象中介者角色

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

Concrete Mediator:具体中介者角色

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

Colleague:同事角色*

每一个同事角色都知道中介者角色，而且与其它的同事角色通信的时候，一定要通过中介者角色来协作。

每个同事类的行为分为二种：一种是同事本身的行为，这种行为叫做自发行为(Self-Method);第二种是必须依赖中介者才能完成的行为，叫做依赖行为(Dep-Method)。

---

2.具体实例

抽象中介者:

/**
 * @author Jay
 * @date 2019/7/6 19:05
 * @description 中介者
 */
public abstract class Mediator {

    /**
     * 定义一个抽象的发送消息方法
     * 功能：得到同事对象和发送消息
     *
     * @param message
     * @param colleague
     */
    public abstract void send(String message, Colleague colleague);
}

抽象同事类:

/**
 * @author Jay
 * @date 2019/7/6 19:06
 * @description
 */
public abstract class Colleague {
    protected Mediator mediator;

    /**
     * 构造方法，得到中介者对象
     */
    public Colleague() {
        this.mediator = mediator;
    }
}

中介者实现类:

/**
 * @author Jay
 * @date 2019/7/6 19:07
 * @description
 */
public class ConcreteMediator extends Mediator {
    ConcreteColleagueA colleagueA;
    ConcreteColleagueB colleagueB;


    /**
     * 重写发送消息的方法，根据具体发送消息的对象去通知接收消息的对象
     *
     * @param message
     * @param colleague
     */
    @Override
    public void send(String message, Colleague colleague) {
        if (colleague == colleagueA) {
            colleagueB.notify(message);
        } else {
            colleagueA.notify(message);
        }

    }
}

具体同事

public class ConcreteColleagueA extends Colleague   {

    public ConcreteColleagueA(Mediator mediator){
        this.mediator = mediator;
    }

    public void send(String message){
        /**
         * 消息是通过中介者发送出去的
         */
        mediator.send(message,this);
    }

    public void notify(String message){
        System.out.println("A同事收到消息：" + message);
    }
}
public class ConcreteColleagueB extends Colleague {
    public ConcreteColleagueB(Mediator mediator) {
        this.mediator = mediator;
    }

    public void send(String message) {
        //消息是通过中介者发送出去的
        mediator.send(message, this);
    }

    public void notify(String message) {
        System.out.println("B同事收到消息：" + message);
    }
}

测试类

/**
 * @author Jay
 * @date 2019/7/6 19:13
 * @description
 */
public class Test {
    public static void main(String[] args) {
        ConcreteMediator mediator = new ConcreteMediator();

        //让两个具体同事类对象认识中介者对象
        ConcreteColleagueA colleagueA = new ConcreteColleagueA(mediator);
        ConcreteColleagueB colleagueB = new ConcreteColleagueB(mediator);

        mediator.colleagueA = colleagueA;
        mediator.colleagueB = colleagueB;

        colleagueA.send("hi,nice to meet you!");
        colleagueB.send("nice to meet you too!");
    }
}

调停者模式的一个潜在缺点是，过度集中化。如果同事对象的交互非常多，而且比较复杂，当这些复杂性全部集中到调停者的时候，会导致调停者对象变得十分复杂，而且难于管理和维护。

迪米特原则 ,如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果需要相互调用，可以通过第三方来转发.

---

To GitHub