每天学习一个设计模式（十七）：行为型之中介者模式

一、基本概念

中介者模式的定义为：Define an object that encapsulates how a set of objects interact.Mediator promotesloose coupling by keeping objects from referring to each other explicitly,and it lets you vary theirinteraction independently.（用一个中介对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使其耦合松散，而且可以独立地改变它们之间的交互。）

二、通俗解释

中介者模式又称为MEDIATOR调停者模式：四个MM打麻将，相互之间谁应该给谁多少钱算不清楚了，幸亏当时我在旁边，按照各自的筹码数算钱，赚了钱的从我这里拿，赔了钱的也付给我，一切就OK啦，俺得到了四个MM的电话。 调停者模式：调停者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显作用。从而使他们可以松散偶合。当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互作用转化为一对多的相互作用。调停者模式将对象的行为和协作抽象化，把对象在小尺度的行为上与其他对象的相互作用分开处理。

三、中介者模式详解

1.通用模版

中介者模式通用类图如图所示。

从类图中看，中介者模式由以下几部分组成：

●Mediator 抽象中介者角色

抽象中介者角色定义统一的接口，用于各同事角色之间的通信。

●Concrete Mediator 具体中介者角色

具体中介者角色通过协调各同事角色实现协作行为，因此它必须依赖于各个同事角色。

●Colleague 同事角色

每一个同事角色都知道中介者角色，而且与其他的同事角色通信的时候，一定要通过中介者角色协作。每个同事类的行为分为两种：一种是同事本身的行为，比如改变对象本身的状态，处理自己的行为等，这种行为叫做自发行为（Self-Method），与其他的同事类或中介者没有任何的依赖；第二种是必须依赖中介者才能完成的行为，叫做依赖方法（Dep-Method）。

中介者模式比较简单，其通用源码也比较简单，先看抽象中介者Mediator类。

public abstract class Mediator {
    /**
     * 定义同事类
     */
    protected ConcreteColleague1 c1;
    protected ConcreteColleague2 c2;

    /**
     * 通过getter/setter方法把同事类注入进来
     *
     * @return
     */
    public ConcreteColleague1 getC1() {
        return c1;
    }

    public void setC1(ConcreteColleague1 c1) {
        this.c1 = c1;
    }

    public ConcreteColleague2 getC2() {
        return c2;
    }

    public void setC2(ConcreteColleague2 c2) {
        this.c2 = c2;
    }

    /**
     * 中介者模式的业务逻辑
     */
    public abstract void doSomething1();

    public abstract void doSomething2();
}

在Mediator抽象类中我们只定义了同事类的注入，为什么使用同事实现类注入而不使用抽象类注入呢？那是因为同事类虽然有抽象，但是没有每个同事类必须要完成的业务方法，当然如果每个同事类都有相同的方法，比如execute、handler等，那当然注入抽象类，做到依赖倒置。

具体的中介者一般只有一个，即通用中介者。

public class ConcreteMediator extends Mediator{
    @Override
    public void doSomething1() {
        //调用同事类的方法，只要是public方法都可以调用
        super.c1.selfMethod1();
        super.c2.selfMethod2();
    }

    @Override
    public void doSomething2() {
        super.c1.selfMethod1();
        super.c2.selfMethod2();
    }
}

中介者所具有的方法doSomething1和doSomething2都是比较复杂的业务逻辑，为同事类服务，其实现是依赖各个同事类来完成的。

抽象同事类

public abstract class Colleague {
    protected Mediator mediator;

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

这个基类也非常简单。一般来说，中介者模式中的抽象都比较简单，是为了建立这个中介而服务的，具体同事类如下：

public class ConcreteColleague1 extends Colleague {
    public ConcreteColleague1(Mediator mediator) {
        super(mediator);
    }

    public void selfMethod1() {
        //自有方法，业务逻辑处理
    }

    public void depMethod1() {
        //依赖方法，自己不能处理的业务逻辑，委托给中介者处理
        super.mediator.doSomething1();
    }
}

public class ConcreteColleague2 extends Colleague{
    public ConcreteColleague2(Mediator mediator) {
        super(mediator);
    }

    public void selfMethod2() {
        //自有方法，业务逻辑处理
    }

    public void depMethod2() {
        //依赖方法，自己不能处理的业务逻辑，委托给中介者处理
        super.mediator.doSomething2();
    }
}

为什么同事类要使用构造函数注入中介者，而中介者使用getter/setter方式注入同事类呢？这是因为同事类必须有中介者，而中介者却可以只有部分同事类。

2.进销存管理的例子

大家都来自五湖四海，都要生存，于是都找了个靠山——公司，就是给你发薪水的地方。公司要想尽办法赢利赚钱，赢利方法则不尽相同，但是各个公司都有相同的三个环节：采购、销售和库存。这个怎么说呢？比如一个软件公司，要开发软件，就需要购买开发环境，如Windows操作系统、数据库产品等，这就是采购；开发完产品还要把产品推销出去；有产品就必然有库存，软件产品也有库存，虽然不需要占用库房空间，但也要占用光盘或硬盘，这也是库存。再比如做咨询服务的公司，它要采购什么？采购知识，采购经验，这是这类企业的生存之本，销售的也是知识和经验，库存同样是知识和经验。既然进销存是如此重要，我们今天就来讲讲它的原理和设计，我相信很多人都已经开发过这种类型的软件，基本上都形成了固定套路，不管是单机版还是网络版，一般的做法都是通过数据库来完成相关产品的管理，相对来说这还是比较简单的项目，三个模块的示意图如图所示。

我们从这个示意图上可以看出，三个模块是相互依赖的。我们就以一个终端销售商（以服务最终客户为目标的企业，比如某某超市、某某商店等）为例，采购部门要采购IBM的电脑，它根据以下两个要素来决定采购数量。

●销售情况

销售部门要反馈销售情况，畅销就多采购，滞销就不采购。

●库存情况

即使是畅销产品，库存都有1000台了，每天才卖出去10台，也就不需要再采购了！销售模块是企业的赢利核心，对其他两个模块也有影响：

●库存情况

库房有货，才能销售，空手套白狼是不行的。

●督促采购

在特殊情况下，比如一个企业客户要一次性购买100台电脑，库存只有80台，这时需要催促采购部门赶快采购！

同样地，库存管理也对其他两个模块有影响。库房是有容积限制的，不可能无限大，所以就有了清仓处理，那就要求采购部门停止采购，同时销售部门进行打折销售。

从以上分析来看，这三个模块都有自己的行为，并且与其他模块之间的行为产生关联，类似于我们办公室的同事，大家各干各的活，但是彼此之间还是有交叉的，于是彼此之间就产生紧耦合，也就是一个团队。我们先来实现这个进销存，类图如图所示。

Purchase负责采购管理，buyIBMComputer指定了采购IBM电脑，refuseBuyIBM是指不再采购IBM了。

public class Purchase {
    /**
     * 采购IBM电脑
     *
     * @param number
     */
    public void buyIBMComputer(int number) {
        //访问库存
        Stock stock = new Stock();
        //访问销售
        Sale sale = new Sale();
        //电脑的销售情况
        int saleStatus = sale.getSaleStatus();
        if (saleStatus > 80) {
            //销售情况良好
            System.out.println("采购IBM电脑：" + number + "台");
        } else {
            //销售情况不好,折半采购
            int buyNumber = number / 2;
            System.out.println("采购IBM电脑：" + buyNumber + "台");
        }
    }

    public void refuseBuyIBM() {
        System.out.println("不再采购IBM电脑");
    }
}

Purchase定义了采购电脑的标准：如果销售情况比较好，大于80分，你让我采购多少我就采购多少；销售情况不好，你让我采购100台，我就采购50台，对折采购。电脑采购完毕，需要放到库房中，因此要调用库存的方法，增加库存电脑数量。我们继续来看库房Stock类。

public class Stock {
    /**
     * 初始库存100台
     */
    private static int COMPUTER_NUMBER = 100;

    /**
     * 增加库存
     *
     * @param number
     */
    public void increase(int number) {
        COMPUTER_NUMBER += number;
        System.out.println("库存数量为：" + COMPUTER_NUMBER);
    }

    /**
     * 降低库存
     *
     * @param number
     */
    public void decrease(int number) {
        COMPUTER_NUMBER -= number;
        System.out.println("库存数量为：" + COMPUTER_NUMBER);
    }

    /**
     * 获得库存数量
     *
     * @return
     */
    public int getStockNumber() {
        return COMPUTER_NUMBER;
    }

    /**
     * 库存压力大了，就要通知采购人员不要采购，销售要尽快折价销售
     */
    public void clearStock() {
        Purchase purchase = new Purchase();
        Sale sale = new Sale();
        System.out.println("清理库存数量为：" + COMPUTER_NUMBER);
        //要求折价销售
        sale.offSale();
        //要求采购人员不要采购
        purchase.refuseBuyIBM();
    }
}

库房中的货物数量肯定有增减，同时库房还有一个容量显示，达到一定的容量后就要求对一些商品进行折价处理，以腾出更多的空间容纳新产品。于是就有了clearStock方法，既然是清仓处理肯定就要折价销售了。于是在Sale类中就有了offSale方法，我们来看Sale源代码。

public class Sale {
    /**
     * 销售IBM电脑
     *
     * @param number
     */
    public void sellIBMComputer(int number) {
        //访问库存
        Stock stock = new Stock();
        //访问采购
        Purchase purchase = new Purchase();
        if (stock.getStockNumber() < number) {
            //库存数量不够销售
            purchase.buyIBMComputer(number);
        }
        System.out.println("销售IBM电脑" + number + "台");
        stock.decrease(number);
    }

    /**
     * 折价处理
     */
    public void offSale() {
        //库房有多少卖多少
        Stock stock = new Stock();
        System.out.println("折价销售IBM电脑" + stock.getStockNumber() + "台");
    }

    /**
     * 反馈销售情况，0~100之间变化，0代表根本没人卖，100代表非常畅销，出一个卖一个
     *
     * @return
     */
    public int getSaleStatus() {
        Random random = new Random(System.currentTimeMillis());
        int saleStatus = random.nextInt(100);
        System.out.println("IBM电脑的销售情况为：" + saleStatus);
        return saleStatus;
    }
}

Sale类中的getSaleStatus是获得销售情况，这个当然要出现在Sale类中了。记住要把恰当的类放到恰当的类中，销售情况只有销售人员才能反馈出来，通过百分制的机制衡量销售情况。我们再来看场景类是怎么运行的。

public class Client {
    public static void main(String[] args) {
        System.out.println("-----采购人员采购电脑-----");
        Purchase purchase = new Purchase();
        purchase.buyIBMComputer(100);

        System.out.println("\n-----销售人员销售电脑-----");
        Sale sale = new Sale();
        sale.sellIBMComputer(1);

        System.out.println("\n-----库房管理清库处理-----");
        Stock stock = new Stock();
        stock.clearStock();
    }
}

我们在场景类中模拟了三种人员的活动：采购人员采购电脑，销售人员销售电脑，库管员管理库存。运行结果如下所示：

-----采购人员采购电脑-----
IBM电脑的销售情况为：89
采购IBM电脑：100台
库存数量为：200

-----销售人员销售电脑-----
销售IBM电脑1台
库存数量为：199

-----库房管理清库处理-----
清理库存数量为：199
折价销售IBM电脑199台
不再采购IBM电脑

运行结果也是我们期望的，三个不同类型的参与者完成了各自的活动。你有没有发现这三个类是彼此关联的？每个类都与其他两个类产生了关联关系。迪米特法则认为“每个类只和朋友类交流”，这个朋友类并非越多越好，朋友类越多，耦合性越大，要想修改一个就得修改一片，这不是面向对象设计所期望的，况且这还是仅三个模块的情况，属于比较简单的一个小项目。我们把进销存扩展一下，如图所示。

这是一个蜘蛛网的结构，别说是编写程序了，就是给人看估计也能让一大批人昏倒！每个对象都需要和其他几个对象交流，对象越多，每个对象要交流的成本也就越大了，只是维护这些对象的交流就能让一大批程序员望而却步！从这方面来说，我们已经发现设计的缺陷了，作为一个架构师，发现缺陷就要想办法修改。

大家都学过网络的基本知识，网络拓扑有三种类型：总线型、环型、星型。星型网络拓扑如图所示。

在星型网络拓扑中，每个计算机通过交换机和其他计算机进行数据交换，各个计算机之间并没有直接出现交互的情况。这种结构简单，而且稳定，只要中间那个交换机不瘫痪，整个网络就不会发生大的故障。公司和网吧一般都采用星型网络。我们是不是可以把这种星型结构引入到我们的设计中呢？我们先画一个示意图，如图所示。

加入了一个中介者作为三个模块的交流核心，每个模块之间不再相互交流，要交流就通过中介者进行。每个模块只负责自己的业务逻辑，不属于自己的则丢给中介者来处理，简化了各模块之间的耦合关系，类图如图所示。

建立了两个抽象类AbstractMediator和AbstractColeague，每个对象只是与中介者Mediator之间产生依赖，与其他对象之间没有直接关系，AbstractMediator的作用是实现中介者的抽象定义，定义了一个抽象方法execute。

抽象中介者

public abstract class AbstractMediator {
    protected Purchase purchase;
    protected Sale sale;
    protected Stock stock;

    /**
     * 构造函数
     */
    public AbstractMediator() {
        this.purchase = new Purchase();
        this.sale = new Sale();
        this.stock = new Stock();
    }

    /**
     * 中介者最重要的方法叫做事件方法，处理多个对象之间的关系
     *
     * @param str
     * @param objects
     */
    public abstract void execute(String str, Object... objects);
}

再来看具体的中介者，我们可以根据业务的要求产生多个中介者，并划分各中介者的职责。

具体中介者

public class Mediator extends AbstractMediator {
    /**
     * 中介者最重要的执行方法
     *
     * @param str
     * @param objects
     */
    @Override
    public void execute(String str, Object... objects) {
        switch (str) {
            case "purchase.buy":
                this.buyComputer((Integer) objects[0]);
                break;
            case "sale.sell":
                this.sellComputer((Integer) objects[0]);
                break;
            case "sale.offsell":
                this.offSell();
                break;
            case "stock.clear":
                this.clearStock();
                break;
            default:
                break;
        }
    }

    /**
     * 采购电脑
     *
     * @param number
     */
    private void buyComputer(int number) {
        //电脑的销售情况
        int saleStatus = super.sale.getSaleStatus();
        if (saleStatus > 80) {
            //销售情况良好
            System.out.println("采购IBM电脑：" + number + "台");
            super.stock.increase(number);
        } else {
            //销售情况不好,折半采购
            int buyNumber = number / 2;
            System.out.println("采购IBM电脑：" + buyNumber + "台");
            super.stock.increase(buyNumber);
        }
    }

    /**
     * 销售电脑
     *
     * @param number
     */
    public void sellComputer(int number) {
        if (super.stock.getStockNumber() < number) {
            //库存数量不够销售
            super.purchase.buyIBMComputer(number);
        }
        System.out.println("销售IBM电脑" + number + "台");
        super.stock.decrease(number);
    }

    /**
     * 折价处理
     */
    public void offSell() {
        System.out.println("折价销售IBM电脑" + super.stock.getStockNumber() + "台");
    }

    /**
     * 清仓处理
     */
    public void clearStock() {
        //要求折价销售
        super.sale.offSale();
        //要求采购人员不要采购
        super.purchase.refuseBuyIBM();
    }
}

中介者Mediator定义了多个private方法，其目的是处理各个对象之间的依赖关系，就是说把原有一个对象要依赖多个对象的情况移到中介者的private方法中实现。在实际项目中，一般的做法是中介者按照职责进行划分，每个中介者处理一个或多个类似的关联请求。由于要使用中介者，我们增加了一个抽象同事类，三个具体的实现类分别继承该抽象类。

public abstract class AbstractColleague {
    protected AbstractMediator mediator;

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

修改后的采购管理

public class Purchase extends AbstractColleague {
    public Purchase(AbstractMediator mediator) {
        super(mediator);
    }

    /**
     * 采购IBM电脑
     *
     * @param number
     */
    public void buyIBMComputer(int number) {
        super.mediator.execute("purchase.buy", number);
    }

    public void refuseBuyIBM() {
        System.out.println("不再采购IBM电脑");
    }
}

上述Purchase类简化了很多，也清晰了很多，处理自己的职责，与外界有关系的事件处理则交给了中介者来完成。再来看Stock类。

修改后的库存管理

public class Stock extends AbstractColleague {
    /**
     * 初始库存100台
     */
    private static int COMPUTER_NUMBER = 100;

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

    /**
     * 增加库存
     *
     * @param number
     */
    public void increase(int number) {
        COMPUTER_NUMBER += number;
        System.out.println("库存数量为：" + COMPUTER_NUMBER);
    }

    /**
     * 降低库存
     *
     * @param number
     */
    public void decrease(int number) {
        COMPUTER_NUMBER -= number;
        System.out.println("库存数量为：" + COMPUTER_NUMBER);
    }

    /**
     * 获得库存数量
     *
     * @return
     */
    public int getStockNumber() {
        return COMPUTER_NUMBER;
    }

    /**
     * 库存压力大了，就要通知采购人员不要采购，销售要尽快折价销售
     */
    public void clearStock() {
        System.out.println("清理库存数量为：" + COMPUTER_NUMBER);
        super.mediator.execute("stock.clear");
    }
}

修改后的销售管理

public class Sale extends AbstractColleague {
    public Sale(AbstractMediator mediator) {
        super(mediator);
    }

    /**
     * 销售IBM电脑
     *
     * @param number
     */
    public void sellIBMComputer(int number) {
        super.mediator.execute("sale.sell", number);
    }

    /**
     * 折价处理
     */
    public void offSale() {
        super.mediator.execute("sale.offsell");
    }

    /**
     * 反馈销售情况，0~100之间变化，0代表根本没人卖，100代表非常畅销，出一个卖一个
     *
     * @return
     */
    public int getSaleStatus() {
        Random random = new Random(System.currentTimeMillis());
        int saleStatus = random.nextInt(100);
        System.out.println("IBM电脑的销售情况为：" + saleStatus);
        return saleStatus;
    }
}

增加了中介者，场景类也需要小小的改动，修改后的场景类

public class Client {
    public static void main(String[] args) {
        AbstractMediator mediator = new Mediator();
        System.out.println("-----采购人员采购电脑-----");
        Purchase purchase = new Purchase(mediator);
        purchase.buyIBMComputer(100);

        System.out.println("\n-----销售人员销售电脑-----");
        Sale sale = new Sale(mediator);
        sale.sellIBMComputer(1);

        System.out.println("\n-----库房管理清库处理-----");
        Stock stock = new Stock(mediator);
        stock.clearStock();
    }
}

在场景类中增加了一个中介者，然后分别传递到三个同事类中，三个类都具有相同的特性：只负责处理自己的活动（行为），与自己无关的活动就丢给中介者处理，程序运行的结果是相同的。从项目设计上来看，加入了中介者，设计结构清晰了很多，而且类间的耦合性大大减少，代码质量也有了很大的提升。在多个对象依赖的情况下，通过加入中介者角色，取消了多个对象的关联或依赖关系，减少了对象的耦合性。

3.中介者模式的优缺点

中介者模式的优点

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

中介者模式的缺点

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

4.中介者模式的应用

使用场景

中介者模式简单，但是简单不代表容易使用，很容易被误用。在面向对象的编程中，对象和对象之间必然会有依赖关系，如果某个类和其他类没有任何相互依赖的关系，那这个类就是一个“孤岛”，在项目中就没有存在的必要了！就像是某个人如果永远独立生活，与任何人都没有关系，那这个人基本上就算是野人了——排除在人类这个定义之外。

类之间的依赖关系是必然存在的，一个类依赖多个类的情况也是存在的，存在即合理，那是否可以说只要有多个依赖关系就考虑使用中介者模式呢？答案是否定的。中介者模式未必能帮你把原本凌乱的逻辑整理得清清楚楚，而且中介者模式也是有缺点的，这个缺点在使用不当时会被放大，比如原本就简单的几个对象依赖关系，如果为了使用模式而加入了中介者，必然导致中介者的逻辑复杂化，因此中介者模式的使用需要“量力而行”！中介者模式适用于多个对象之间紧密耦合的情况，紧密耦合的标准是：在类图中出现了蜘蛛网状结构。在这种情况下一定要考虑使用中介者模式，这有利于把蜘蛛网梳理为星型结构，使原本复杂混乱的关系变得清晰简单。

实际应用

中介者模式也叫做调停者模式，是什么意思呢？一个对象要和N多个对象交流，就像对象间的战争，很混乱。这时，需要加入一个中心，所有的类都和中心交流，中心说怎么处理就怎么处理，我们举一些在开发和生活中经常会碰到的例子。

●机场调度中心

大家在每个机场都会看到有一个“××机场调度中心”，它就是具体的中介者，用来调度每一架要降落和起飞的飞机。比如，某架飞机（同事类）飞到机场上空了，就询问调度中心（中介者）“我是否可以降落”以及“降落到哪个跑道”，调度中心（中介者）查看其他飞机（同事类）情况，然后通知飞机降落。如果没有机场调度中心，飞机飞到机场了，飞行员要先看看有没有飞机和自己一起降落的，有没有空跑道，停机位是否具备等情况，这种局面是难以想象的！

●MVC框架

大家都应该使用过Struts，MVC框架，其中的C（Controller）就是一个中介者，叫做前端控制器(FrontController)，它的作用就是把M(Model，业务逻辑)和V（View，视图）隔离开，协调M和V协同工作，把M运行的结果和V代表的视图融合成一个前端可以展示的页面，减少M和V的依赖关系。MVC框架已经成为一个非常流行、成熟的开发框架，这也是中介者模式的优点的一个体现。

●媒体网关

媒体网关也是一个典型的中介者模式，比如使用MSN时，张三发消息给李四，其过程应该是这样的：张三发送消息，MSN服务器(中介者)接收到消息，查找李四，把消息发送到李四，同时通知张三，消息已经发送。在这里，MSN服务器就是一个中转站，负责协调两个客户端的信息交流，与此相反的就是IPMsg（也叫飞鸽），它没有使用中介者，而直接使用了UDP广播的方式，每个客户端既是客户端也是服务器端。

●中介服务

现在中介服务非常多，比如租房中介、出国中介，这些也都是中介模式的具体体现，比如你去租房子，如果没有房屋中介，你就必须一个一个小区去找，看看有没有空房子，有没有适合自己的房子，找到房子后还要和房东签合约，自己检查房屋的家具、水电煤等；有了中介后，你就省心多了，找中介，然后安排看房子，看中了，签合约，中介帮你检查房屋家具、水电煤等等。这也是中介模式的实际应用。

最佳实践

中介者模式很少用到接口或者抽象类，这与依赖倒置原则是冲突的，这是什么原因呢？首先，既然是同事类而不是兄弟类（有相同的血缘），那就说明这些类之间是协作关系，完成不同的任务，处理不同的业务，所以不能在抽象类或接口中严格定义同事类必须具有的方法（从这点也可以看出继承是高侵入性的）。这是不合适的，就像你我是同事，虽然我们大家都是朝九晚五地上班，但是你跟我干的活肯定不同，不可能抽象出一个父类统一定义同事所必须有的方法。当然，每个同事都要吃饭、上厕所，可以把这些最基本的信息封装到抽象中，但这些最基本的行为或属性是中介者模式要关心的吗？如果两个对象不能提炼出共性，那就不要刻意去追求两者的抽象，抽象只要定义出模式需要的角色即可。当然如果严格遵守面向接口编程的话，则是需要抽象的，这就需要读者在实际开发中灵活掌握。其次，在一个项目中，中介者模式可能被多个模块采用，每个中介者所围绕的同事类各不相同，你能抽象出一个具有共性的中介者吗？不可能，一个中介者抽象类一般只有一个实现者，除非中介者逻辑非常复杂，代码量非常大，这时才会出现多个中介者的情况。所以，对于中介者来说，抽象已经没有太多的必要。

中介者模式是一个非常好的封装模式，也是一个很容易被滥用的模式，一个对象依赖几个对象是再正常不过的事情，但是纯理论家就会要求使用中介者模式来封装这种依赖关系，这是非常危险的！使用中介模式就必然会带来中介者的膨胀问题，这在一个项目中是很不恰当的。大家可以在如下的情况下尝试使用中介者模式：

N个对象之间产生了相互的依赖关系（N＞2）。多个对象有依赖关系，但是依赖的行为尚不确定或者有发生改变的可能，在这种情况下一般建议采用中介者模式，降低变更引起的风险扩散。产品开发。一个明显的例子就是MVC框架，把中介者模式应用到产品中，可以提升产品的性能和扩展性，但是对于项目开发就未必，因为项目是以交付投产为目标，而产品则是以稳定、高效、扩展为宗旨。

---

参考秦小波的《设计模式之禅（第2版）》