[工作中的设计模式]中介模式模式Mediator

一、模式解析

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

中介模式又叫调停者模式，他有如下特点：

1、有多个系统或者对象发生交互，但又不能直接进行交互；

2、通过一个中介者来保留所有的交互对象（又叫同事类）的引用；

3、同事类同事也需要保留中介者的引用，以便调用中介者中的方法与其他同事类发生交互

4、中介者根据实际情况，如果系统复杂，有多个中介者，那么可以编写抽象中介者，如果没有则直接编写具体中介者

二、模式代码

1、抽象同事类

package mediator.patten;

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

2、抽象中介者

package mediator.patten;
/**
 * 抽象中介者
 * @author zjl
 * @time 2016-2-12
 *
 */
public abstract class Mediator {
    public abstract void send(String msg,Colleague colleague);
}

3、具体同事类1

package mediator.patten;

public class ConcreteColleague1 extends Colleague {

    public ConcreteColleague1(Mediator mediator) {
        super(mediator);
    }
    public void send(String message){
        mediator.send(message, this);
    }
    public void notify(String message){
        System.out.println("同事1得到的消息为："+message);
    }

}

4.具体同事类2

package mediator.patten;

public class ConcreteColleague2 extends Colleague {

    public ConcreteColleague2(Mediator mediator) {
        super(mediator);
    }
    public void send(String message){
        mediator.send(message, this);
    }
    public void notify(String message){
        System.out.println("同事2得到的消息为："+message);
    }

}

5、具体中介者

package mediator.patten;

public class ConcreteMediator extends Mediator {
    private ConcreteColleague1 colleague1;
    private ConcreteColleague2 colleague2;
    
    
    public void setColleague1(ConcreteColleague1 colleague){
        this.colleague1=colleague;
    }
    public void setColleague2(ConcreteColleague2 colleague){
        this.colleague2=colleague;
    }

    @Override
    public void send(String msg, Colleague colleague) {
        if(colleague==colleague1){
            colleague2.notify(msg);
        }else {
            colleague1.notify(msg);
        }
    }

}

5、客户端代码

package mediator.patten;

public class Client {
    public static void main(String[] args) {
        ConcreteMediator mediator=new ConcreteMediator();
        ConcreteColleague1 colleague1=new ConcreteColleague1(mediator);
        ConcreteColleague2 colleague2=new ConcreteColleague2(mediator);
        
        mediator.setColleague1(colleague1);
        mediator.setColleague2(colleague2);
        
        colleague1.send("吃饭了吗？");
        colleague2.send("吃过了");
    }
}

6、执行结果

同事2得到的消息为：吃饭了吗？
同事1得到的消息为：吃过了

三、模式分析

　　1、中介者模式使用了中介类，保存了所有同事类的引用，将同事类的关联进行了解耦，但是会大大增加中介类的复杂度。

　　2、中介类和同事类由于传递交互的要求，形成了彼此调用，加大了使用难度。 

　　3、中介类不仅需要保存同事类的引用，还需要记录他们之间的交互要求，判断每次交互应该发送给哪个同事类。

针对第3点，案例中的交互要求是传递了自身的引用，觉得是不合理，应该改为传递需要交互对象的特殊标示符，虽然理论上中介模式需要对对象的关联进行解耦，但是个人因为对象之间的关系仍然需要保存，否则按照模式标准代码，仅仅增加一个同事3，就会造成无法进行处理。

针对1和2仅能在发生互相的网状调用时，对代码进行检查，是否设计问题，总之此模式比较复杂，需要慎用。

四、应用场景

　　在工作中似乎很少接触到一个系统中中介者模式的使用，但我们对于系统间可以看到目前流行的银行综合前置和企业esb均为此模式的使用，应用系统开发时候，仅需要实现esb指定的接口模式，与银行其他系统的通讯格式由esb自动完成匹配，并且传输到指定的系统。

　　特别强调:应用系统需要保存的是esb指定地址和每个请求的交易代码，也就是我们3.1和3.3的内容

五、场景代码

　　由于在一个系统中暂时未找到合适场景，所以暂略。