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

时间:2023-01-02 17:49:41

一、模式解析

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

中介模式又叫调停者模式,他有如下特点:

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的内容

五、场景代码

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