中介者模式(Mediator):用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。
 
通用类图:
 
举例:在一个公司里面,有很多部门、员工(我们统称他们互相为Colleague“同事”),为了完成一定的任务,“同事”之间肯定有许多需要互相配合、交流的过程。如果由各个“同事”频繁地到处去与自己有关的“同事”沟通,这样肯定会形成一个多对多的杂乱的联系网络而造成工作效率低下。
 
此时就需要一位专门的“中介者”给各个“同事”分配任务,以及统一跟进大家的进度并在“同事”之间实时地进行交互,保证“同事”之间必须的沟通交流。很明显我们知道此时的“中介者”担任了沟通“同事”彼此之间的重要角色了,“中介者”使得每个“同事”都变成一对一的联系方式,减轻了每个“同事”的负担,增强工作效率。
 
大概理清上面简单例子中的意图之后,给出中介者模式适用场景:
1、一组对象以定义良好但是复杂的方式进行通信。产生的相互依赖关系结构混乱且难以理解。
2、一个对象引用其他很多对象并且直接与这些对象通信,导致难以复用该对象。
3、想定制一个分布在多个类中的行为,而又不想生成太多的子类。
 
其实,中介者模式又被称为“调停者”模式,我们可以理解为一群小孩子(同事)吵架了,这时就很需要一位大人(调停者)过来处理好小孩子们的关系,以免发生不必要的冲突。“中介者”和“调停者”只不过是同一个英语单词“Mediator”的不同翻译罢了。反正最最重要的是:中介者就是一个处于众多对象,并恰当地处理众多对象之间相互之间的联系的角色。
 
下面给出具体的代码例子,对比通用类图增加了AbstractColleague抽象同事类和AbstractMediator抽象中介者,另外就是两个具体同事类和一个具体中介者,代码中有较多注释,相应类图也不给出了,应该不难理解的:

同事类族:
//抽象同事类
abstract class AbstractColleague {
    protected AbstractMediator mediator;  

    /**既然有中介者,那么每个具体同事必然要与中介者有联系,
     * 否则就没必要存在于 这个系统当中,这里的构造函数相当
     * 于向该系统中注册一个中介者,以取得联系
     */
    public AbstractColleague(AbstractMediator mediator) {
        this.mediator = mediator;
    }  

    // 在抽象同事类中添加用于与中介者取得联系(即注册)的方法
    public void setMediator(AbstractMediator mediator) {
        this.mediator = mediator;
    }
}  

//具体同事A
class ColleagueA extends AbstractColleague {  

    //每个具体同事都通过父类构造函数与中介者取得联系
    public ColleagueA(AbstractMediator mediator) {
        super(mediator);
    }  

    //每个具体同事必然有自己分内的事,没必要与外界相关联
    public void self() {
        System.out.println("同事A --> 做好自己分内的事情 ...");
    }  

    //每个具体同事总有需要与外界交互的操作,通过中介者来处理这些逻辑并安排工作
    public void out() {
        System.out.println("同事A --> 请求同事B做好分内工作 ...");
        super.mediator.execute("ColleagueB", "self");
    }
}  

//具体同事B
class ColleagueB extends AbstractColleague {  

    public ColleagueB(AbstractMediator mediator) {
        super(mediator);
    }  

    public void self() {
        System.out.println("同事B --> 做好自己分内的事情 ...");
    }  

    public void out() {
        System.out.println("同事B --> 请求同事A做好分内工作  ...");
        super.mediator.execute("ColleagueA", "self");
    }
} 

中介者类族:

//抽象中介者
abstract class AbstractMediator {  

    //中介者肯定需要保持有若干同事的联系方式
    protected Hashtable<String, AbstractColleague> colleagues = new Hashtable<String, AbstractColleague>();  

    //中介者可以动态地与某个同事建立联系
    public void addColleague(String name, AbstractColleague c) {
        this.colleagues.put(name, c);
    }     

    //中介者也可以动态地撤销与某个同事的联系
    public void deleteColleague(String name) {
        this.colleagues.remove(name);
    }  

    //中介者必须具备在同事之间处理逻辑、分配任务、促进交流的操作
    public abstract void execute(String name, String method);
}  

//具体中介者
class Mediator extends AbstractMediator{  

    //中介者最重要的功能,来回奔波与各个同事之间
    public void execute(String name, String method) {  

        if("self".equals(method)){  //各自做好分内事
            if("ColleagueA".equals(name)) {
                ColleagueA colleague = (ColleagueA)super.colleagues.get("ColleagueA");
                colleague.self();
            }else {
                ColleagueB colleague = (ColleagueB)super.colleagues.get("ColleagueB");
                colleague.self();
            }
        }else { //与其他同事合作
            if("ColleagueA".equals(name)) {
                ColleagueA colleague = (ColleagueA)super.colleagues.get("ColleagueA");
                colleague.out();
            }else {
                ColleagueB colleague = (ColleagueB)super.colleagues.get("ColleagueB");
                colleague.out();
            }
        }
    }
} 

测试类:

//测试类
public class Client {
    public static void main(String[] args) {  

        //创建一个中介者
        AbstractMediator mediator = new Mediator();  

        //创建两个同事
        ColleagueA colleagueA = new ColleagueA(mediator);
        ColleagueB colleagueB = new ColleagueB(mediator);  

        //中介者分别与每个同事建立联系
        mediator.addColleague("ColleagueA", colleagueA);
        mediator.addColleague("ColleagueB", colleagueB);  

        //同事们开始工作
        colleagueA.self();
        colleagueA.out();
        System.out.println("======================合作愉快,任务完成!\n");  

        colleagueB.self();
        colleagueB.out();
        System.out.println("======================合作愉快,任务完成!");
    }
} 

测试结果: 

同事A --> 做好自己分内的事情 ...
同事A --> 请求同事B做好分内工作 ...
同事B --> 做好自己分内的事情 ...
======================合作愉快,任务完成!  

同事B --> 做好自己分内的事情 ...
同事B --> 请求同事A做好分内工作  ...
同事A --> 做好自己分内的事情 ...
======================合作愉快,任务完成!  


虽然以上代码中只有两个具体同事类,并且测试类中也只是创建了两个同事,但是这些我们都可以根据中介者模式的宗旨进行适当地扩展,即增加具体同事类,然后中介者就得担负更加重的任务了。为啥?我们看到上面具体中介者类Mediator中的execute()方法中现在就有一堆冗长的判断代码了。虽然可以把它分解并增加到Mediator类中的其它private方法中,但是具体的业务逻辑是少不了的。
 
所以,在解耦同事类之间的联系的同时,中介者自身也不免任务过重,因为几乎所有的业务逻辑都交代到中介者身上了,可谓是“万众期待”的一个角色了。这就是中介者模式的不足之处了 。 

此外,上面这个代码例子是相当理想的了,有时候我们根本抽取不了“同事”之间的共性来形成一个AbstractColleague抽象同事类,这也大大增加了中介者模式的使用难度。   

修改:

由于上面代码实现中存在 benjielin 前辈提出的“双向关联暴露在App中”的不足之处,根据给出的改进方法2,修改上面代码,如下:

 

修改后的同事类族:

//抽象同事类
abstract class AbstractColleague {
    protected AbstractMediator mediator;      

    //舍去在构造函数中建立起与中介者的联系
//  public AbstractColleague(AbstractMediator mediator) {
//      this.mediator = mediator;
//  }  

    // 在抽象同事类中添加用于与中介者取得联系(即注册)的方法
    public void setMediator(AbstractMediator mediator) {
        this.mediator = mediator;
    }
}  

//具体同事A
class ColleagueA extends AbstractColleague {  

    //舍去在构造函数中建立起与中介者的联系
//  public ColleagueA(AbstractMediator mediator) {
//      super(mediator);
//  }  

    //每个具体同事必然有自己分内的事,没必要与外界相关联
    public void self() {
        System.out.println("同事A --> 做好自己分内的事情 ...");
    }  

    //每个具体同事总有需要与外界交互的操作,通过中介者来处理这些逻辑并安排工作
    public void out() {
        System.out.println("同事A --> 请求同事B做好分内工作 ...");
        super.mediator.execute("ColleagueB", "self");
    }
}  

//具体同事B
class ColleagueB extends AbstractColleague {
    //舍去在构造函数中建立起与中介者的联系
//  public ColleagueB(AbstractMediator mediator) {
//      super(mediator);
//  }  

    public void self() {
        System.out.println("同事B --> 做好自己分内的事情 ...");
    }  

    public void out() {
        System.out.println("同事B --> 请求同事A做好分内工作  ...");
        super.mediator.execute("ColleagueA", "self");
    }
} 

修改后的中介者:

//抽象中介者
abstract class AbstractMediator {  

    //中介者肯定需要保持有若干同事的联系方式
    protected Hashtable<String, AbstractColleague> colleagues = new Hashtable<String, AbstractColleague>();  

    //中介者可以动态地与某个同事建立联系
    public void addColleague(String name, AbstractColleague c) {  

        // 在中介者这里帮助具体同事建立起于中介者的联系
        c.setMediator(this);
        this.colleagues.put(name, c);
    }     

    //中介者也可以动态地撤销与某个同事的联系
    public void deleteColleague(String name) {
        this.colleagues.remove(name);
    }  

    //中介者必须具备在同事之间处理逻辑、分配任务、促进交流的操作
    public abstract void execute(String name, String method);
} 

//测试类
public class Client {
    public static void main(String[] args) {  

        //创建一个中介者
        AbstractMediator mediator = new Mediator();  

        //不用构造函数为具体同事注册中介者来取得联系了
//      ColleagueA colleagueA = new ColleagueA(mediator);
//      ColleagueB colleagueB = new ColleagueB(mediator);  

        ColleagueA colleagueA = new ColleagueA();
        ColleagueB colleagueB = new ColleagueB();  

        //中介者分别与每个同事建立联系
        mediator.addColleague("ColleagueA", colleagueA);
        mediator.addColleague("ColleagueB", colleagueB);  

        //同事们开始工作
        colleagueA.self();
        colleagueA.out();
        System.out.println("======================合作愉快,任务完成!\n");  

        colleagueB.self();
        colleagueB.out();
        System.out.println("======================合作愉快,任务完成!");
    }
} 

本文来自:http://haolloyin.blog.51cto.com/1177454/333810/

java设计模式---调停者模式的更多相关文章

  1. Java设计模式——装饰者模式

    JAVA 设计模式 装饰者模式 用途 装饰者模式 (Decorator) 动态地给一个对象添加一些额外的职责.就增加功能来说,Decorator 模式相比生成子类更为灵活. 装饰者模式是一种结构式模式 ...

  2. 浅析JAVA设计模式之工厂模式(一)

    1 工厂模式简单介绍 工厂模式的定义:简单地说,用来实例化对象,取代new操作. 工厂模式专门负责将大量有共同接口的类实例化.工作模式能够动态决定将哪一个类实例化.不用先知道每次要实例化哪一个类. 工 ...

  3. JAVA设计模式--装饰器模式

    装饰器模式 装饰器模式(Decorator Pattern)允许向一个现有的对象添加新的功能,同时又不改变其结构.这种类型的设计模式属于结构型模式,它是作为现有的类的一个包装. 这种模式创建了一个装饰 ...

  4. 折腾Java设计模式之建造者模式

    博文原址:折腾Java设计模式之建造者模式 建造者模式 Separate the construction of a complex object from its representation, a ...

  5. 折腾Java设计模式之备忘录模式

    原文地址:折腾Java设计模式之备忘录模式 备忘录模式 Without violating encapsulation, capture and externalize an object's int ...

  6. 折腾Java设计模式之状态模式

    原文地址 折腾Java设计模式之状态模式 状态模式 在状态模式(State Pattern)中,类的行为是基于它的状态改变的.这种类型的设计模式属于行为型模式.在状态模式中,我们创建表示各种状态的对象 ...

  7. 折腾Java设计模式之模板方法模式

    博客原文地址:折腾Java设计模式之模板方法模式 模板方法模式 Define the skeleton of an algorithm in an operation, deferring some ...

  8. 折腾Java设计模式之访问者模式

    博客原文地址:折腾Java设计模式之访问者模式 访问者模式 Represent an operation to be performed on the elements of an object st ...

  9. 折腾Java设计模式之命令模式

    博客原文地址 折腾Java设计模式之命令模式 命令模式 wiki上的描述 Encapsulate a request as an object, thereby allowing for the pa ...

随机推荐

  1. 优化Webpack打包速度

    1. Webpack 可以配置 externals 来将依赖的库指向全局变量,从而不再打包这个库,比如对于这样一个文件:   import React from 'react'; console.lo ...

  2. angularjs中关于跨域设置白名单

    在config中注入$sceDelegateProvider服务使用resourceUrlWhitelist([])方法添加白名单 跨域时将method的属性设置为"jsonp"就 ...

  3. JMeter如何和Charles进行接口测试

    什么是接口测试,接口测试到底如何开展,我相信任何一个软件测试人员都会有这样的疑问, 这里我以接口测试自动化平台的登录接口进行讲解. 一.什么是接口测试? 接口测试是测试系统组件间接口的一种测试.接口测 ...

  4. 混合式应用开发之Cordova+vue(1)

    一.Cordova创建应用 cordova create oneApp Cordova创建应用出错 Cordova安装时不能使用cnpm 应该使用npm,cnpm虽然快但是后期出的错绝对比这省下来的时 ...

  5. Hibernate异常之cascade

    org.hibernate.MappingException: Unsupported cascade style: delete-option at org.hibernate.engine.spi ...

  6. Docker端口映射实现

    默认情况下,容器可以主动访问到外部网络的连接,但是外部网络无法访问到容器. 容器访问外部实现 容器所有到外部网络的连接,源地址都会被NAT成本地系统的IP地址.这是使用 iptables 的源地址伪装 ...

  7. 疯狂的Django 之深度外键跨表查找之疯狂INNER JOIN

    定义Model: from django.db import models class Moreinfo(models.Model): weight = models.FloatField() hei ...

  8. Git之(四)分支管理

    当我们初始化Git仓库的时候,Git会默认创建一个名为master的主分支.在实际工作中,主分支要求是一个稳定.健壮.安全的主线,一般不允许在主分支上直接进行开发,而是拉取一个新的分支,开发.测试完成 ...

  9. Swift按照数组元素出现的次数及大小排序

    要求如下: 1.已知一个数组,按照单个元素在数组中出现的次数作为重新排序的依据,个数多的排在前面 2.相同个数时候,元素值大的排前面 例子: [1, 2, 2, 3, 5, 5] 经过计算得到的结果是 ...

  10. Windows运行GitStats

    Windows运行GitStats(金庆的专栏)GitStats - git history statistics generatorhttp://gitstats.sourceforge.net/G ...