一、模式解析
用一个中介者对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使耦合松散，而且可以独立地改变它们之间的交互。
中介模式又叫调停者模式，他有如下特点：
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的内容
五、场景代码
由于在一个系统中暂时未找到合适场景，所以暂略。