设计模式系列之「中介者模式」

2018-02-01 本文已影响53人 YoungManSter

小Y在文章开始之前先回顾一下历史：三省六部制是西晋以后长期发展形成，至隋朝正式确立，唐朝进一步完善的一种政治制度，反映了中国古代君主专制中央集权制度的进一步完善。那么小Y今天的主题就来了—如何最大实现“一省六部”（尚书省、吏部、户部、礼部、兵部、刑部、工部）的效能，Action。

一、前提

尚书省管属下的六部之间相互协调工作，来张图展示一下这错综复杂、爱恨情仇的关系。

为了文章的简洁，小Y不得不裁减部门了，把“一省六部”直接缩减为“一省三部”。

三个部门相互依赖的同时它们也有着自己的职能，小Y就有失偏颇地概括了一下:

户部：管理钱财。
兵部：掌管兵权。
工部：掌管营造工程事项。

二、情景再现

1.天灾造成百姓流离失所，饿殍满地，这下户部麻烦了，心想着责任不能我一个人担啊，死都要拉个垫背的。

对兵部说：饥民太多，恐防出现暴乱，需要军队镇压。
对工部说：灾害损毁房屋太多，需要你们来规划重建。

2.不长眼睛的蛮夷族要攻打天朝，兵部这下就坐不住了，立马找来工部和户部。

对工部说：蛮夷族的战斗力太强悍了，需要通过一些防御工事抵御，这事就交给你们了。
对户部说：要想打胜仗，士兵首先要吃得饱穿得暖，吃穿的钱粮这个重任就非你们莫属了。

3.皇帝老爷的妃子多了，行宫要大批大批的建，工部就抱怨了，为毛皇帝这毛快活就要累死我们，不行，有苦同吃，有难各自飞，这才是兄弟嘛。

对兵部说：陛下要求大规模建行宫，为陛下服务的机会到了哈，调遣大批士兵给我当苦力吧。
对户部说：行官需要设计精美，需要花费的银子不少，需要你们搜刮多点民脂民膏。

三、出谋划策

方案一：尚书省只挂个管理牌就可以，对下面六个部门的工作不干预，爱咋干咋干，关键时刻给我功劳就好。
以尚书省为中心，底下六个部门在工作上不直接进行交流，统一经过尚书
省（中介者模式）。

四、来波广告

1.中介模式的定义

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

2.中介模式的角色介绍

Mediator 抽象中介者角色
抽象中介者角色定义统一的接口，用于各同事角色之间的通信。
Concrete Mediator 具体中介者角色
具体中介者角色通过协调各同事角色实现协作行为，因此它必须依赖于各个同事角色。
Colleague 同事角色
每一个同事角色都知道中介者角色，而且与其他的同事角色通信的时候，一定要通过中介者角色协作。每个同事类的行为分为两种：一种是同事本身的行为，比如改变对象本身的状态，处理自己的行为等，这种行为叫做自发行为，与其他的同事类或中介者没有任何的依赖；第二种是必须依赖中介者才能完成的行为，叫做依赖方法。

3.中介模式的使用场景

在面向对象的编程中，对象和对象之间必然会有依赖关系。
中介者模式适用于多个对象之间紧密耦合的情况，紧密耦合的标准是：在类图中出现了蜘蛛网状结构。

五、方案的实施

1.方案一

发生事情各个部门自行商量解决。

①户部

public class Department {

    public void dealDisaster(){
        System.out.println("户部：专挑轻活，其他的找别人干去。");
        //需要工部规划重建
        Ministry ministry=new Ministry();
        ministry.selfFunction();
        //需要兵部调兵遣将镇压灾民
        Defense defense=new Defense();
        defense.selfFunction();

    }

    public void selfFunction(){
        System.out.println("户部：要钱没问题，我尽量搜刮点民脂民膏。");
    }
}

②兵部

public class Defense {

    public void fight(){
        System.out.println("我只出人，剩下的找别人干去。");
        //需要户部搜刮民脂民膏
        Department department=new Department();
        department.selfFunction();
        //需要工部给图纸建造防御工事
        Ministry ministry=new Ministry();
        ministry.selfFunction();
    }

    public void selfFunction(){
        System.out.println("兵部：要人没问题，我尽量抓多几个壮丁");
    }
}

③工部

public class Ministry {

    public void buildPalace(){
        System.out.println("工部：我只画图纸，其他的找别人干去。");
        //需要户部出钱
        Department department=new Department();
        department.selfFunction();
        //需要兵部调兵遣将加入建造
        Defense defense=new Defense();
        defense.selfFunction();
    }

    public void selfFunction(){
        System.out.println("工部：要建筑图纸没问题，我尽量复制多几份");
    }
}

④Client

public class Client {
    public static void main(String[] args) {
        //发生天灾了，户部麻烦了，需要解决问题
        Department department=new Department();
        department.dealDisaster();
        //要打仗了，兵部的活来了
        Defense defense=new Defense();
        defense.fight();
        //皇帝发话了，工部赶紧建行宫
        Ministry ministry=new Ministry();
        ministry.buildPalace();
    }
}

输出的结果为：

//发生天灾了，户部麻烦了，需要解决问题
户部：专挑轻活，其他的找别人干去。
工部：要建筑图纸没问题，我尽量复制多几份。
兵部：要人没问题，我尽量抓多几个壮丁。

//要打仗了，兵部的活来了
兵部：我只出人，剩下的找别人干去。
户部：要钱没问题，我尽量搜刮点民脂民膏。
工部：要建筑图纸没问题，我尽量复制多几份。

//皇帝发话了，工部赶紧建行宫
工部：我只画图纸，其他的找别人干去。
户部：要钱没问题，我尽量搜刮点民脂民膏。
兵部：要人没问题，我尽量抓多几个壮丁。

三个部门遇到问题都相互协调解决了，没出什么幺蛾子，尚书省也照样得到功劳奖励。从上面的例子发现这三个类是彼此关联的，每个类都与其他两个类产生了关联关系。这样子缺点就暴露出来了，它们彼此关联越多，耦合性越大，要想修改一个就得修改一片，这不是面向对象设计所期望的，上面的例子还是仅三个部门的情况，如果实现上图的六部之间的协调关系，维护起来都要吐血而亡，果断抛弃。

2.方案二（中介者模式）

UML实现

①抽象中介者（尚书省）

public abstract class AbstractMediator {

    protected Department department;
    protected Defense defense;
    protected Ministry ministry;

    public AbstractMediator() {
        department = new Department(this);
        defense=new Defense(this);
        ministry=new Ministry(this);
    }
    
    //中介者最重要的方法叫做事件方法，处理多个对象之间的关系
    public abstract void dealThing(int code);
}

②具体中介者

public class Mediator extends AbstractMediator{

    public static final int DEPARTMENT_CODE=1;
    public static final int DEFENSE_CODE=2;
    public static final int MINISTRY_CODE=3;

    @Override
    public void dealThing(int code) {
        switch (code){
            case DEPARTMENT_CODE:
                this.dealDisaster();
                break;
            case DEFENSE_CODE:
                this.fight();
                break;
            case MINISTRY_CODE:
                this.buildPalace();
                break;
        }
    }
    //户部处理天灾
    private void dealDisaster(){
        System.out.println("户部：专挑轻活，其他的找别人干去。");
        super.ministry.selfFunction();
        super.defense.selfFunction();
    }
    //兵部打仗
    private void fight(){
        System.out.println("兵部：我只出人，剩下的找别人干去。");
        super.department.selfFunction();
        super.ministry.selfFunction();
    }
    //工部建行宫
    private void buildPalace(){
        System.out.println("工部：我只画图纸，其他的找别人干去。");
        super.department.selfFunction();
        super.defense.selfFunction();
    }
}

③抽象部门类

public abstract class AbstractColleague {
    protected AbstractMediator abstractMediator;

    public AbstractColleague(AbstractMediator abstractMediator) {
        this.abstractMediator = abstractMediator;
    }
}

④户部

public class Department extends AbstractColleague{

    public Department(AbstractMediator  abstractMediator) {
    super(abstractMediator);
    }

    public void dealDisaster(){
        super.abstractMediator.dealThing(Mediator.DEPARTMENT_CODE);
    }

    public void selfFunction(){
        System.out.println("要钱没问题，我尽量搜刮点民脂民膏。");
    }
}

⑤兵部

public class Defense extends AbstractColleague{

    public Defense(AbstractMediator abstractMediator) {
        super(abstractMediator);
    }

    public void fight(){
        super.abstractMediator.dealThing(Mediator.MINISTRY_CODE);
    }

    public void selfFunction(){
        System.out.println("兵部：要人没问题，我尽量抓多几个壮丁");
    }
}

⑥工部

public class Ministry extends AbstractColleague{

    public Ministry(AbstractMediator abstractMediator) {
        super(abstractMediator);
    }

    public void buildPalace(){
        super.abstractMediator.dealThing(Mediator.MINISTRY_CODE);
    }

    public void selfFunction(){
        System.out.println("要建筑图纸没问题，我尽量复制多几份");
    }
}

⑦Client

public class Client {
    public static void main(String[] args) {
        AbstractMediator abstractMediator=new Mediator();
        //发生天灾了，户部麻烦了，需要解决问题
        Department department=new Department(abstractMediator);
        department.dealDisaster();
        //要打仗了，兵部的活来了
        Defense defense=new Defense(abstractMediator);
        defense.fight();
        //皇帝发话了，工部赶紧建行宫
        Ministry ministry=new Ministry(abstractMediator);
        ministry.buildPalace();
    }
}

输出的结果为：

//发生天灾了，户部麻烦了，需要解决问题
户部：专挑轻活，其他的找别人干去。
工部：要建筑图纸没问题，我尽量复制多几份。
兵部：要人没问题，我尽量抓多几个壮丁。

//要打仗了，兵部的活来了
兵部：我只出人，剩下的找别人干去。
户部：要钱没问题，我尽量搜刮点民脂民膏。
工部：要建筑图纸没问题，我尽量复制多几份。

//皇帝发话了，工部赶紧建行宫
工部：我只画图纸，其他的找别人干去。
户部：要钱没问题，我尽量搜刮点民脂民膏。
兵部：要人没问题，我尽量抓多几个壮丁。

（1）建立了两个抽象类AbstractMediator和AbstractColeague，每个对象只是与中介者Mediator之间产生依赖，与其他对象之间没有直接关系。

（2）中介者Mediator定义了多个private方法，其目的是处理各个对象之间的依赖关系，就是说把原有一个对象要依赖多个对象的情况移到中介者的private方法中实现。

（3）在场景类中增加了一个中介者，然后分别传递到三个同事类中，三个类都具有相同的特性：只负责处理自己的活动（行为），与自己无关的活动就丢给中介者处理。

（4）在多个对象依赖的情况下，通过加入中介者角色，取消了多个对象的关联或依赖关系，减少了对象的耦合性。

六、中介者模式优缺点

1.优点

中介者模式的优点就是减少类间的依赖，把原有的一对多的依赖变成了一对一的依赖，同事类只依赖中介者，减少了依赖，当然同时也降低了类间的耦合。

2.缺点

中介者模式的缺点就是中介者会膨胀得很大，而且逻辑复杂，原本N个对象直接的相互依赖关系转换为中介者和同事类的依赖关系，同事类越多，中介者的逻辑就越复杂。

七、简单对比观察者模式和中介者模式的区别

1.多个对象之间需要交互，那么这些对象间的交互就会形成网状结构。引入中介者，各对象根本不知道其它对象的存在，他们只需要把信息发送给中介者，由中介者来控制把信息传递给哪些对象。

2.观察者依赖于被观察者的状态改变，两者之间是需要交互的。

八、总结

中介者模式是一个非常好的封装模式，也是一个很容易被滥用的模式，要根据实际情况考虑是否选用中介模式，使用中介模式就必然会带来中介者的膨胀问题，这一点一定要清楚。

Android技术交流吧