23种设计模式-中介者模式

  1. 进销存管理是这个样子的吗

书中通过各个公司的基本模式来引入这个模式，无论是哪个公司都有相同的三个环节：采购、销售和库存（这里不单单是指实际存在的产品，也包括一些没有实质的知识），确实也是这样，不管是哪个行业，都少不了这三个环节，做产品的不提，哪怕是做咨询服务的公司，他也要采购知识经验，这是这类企业的生存之本，销售的也是知识和经验，库存同样是知识和经验。既然进销存是如此重要，我们今天就来学学它的原理和设计，三个模块的示意图如图14-1：

14-1

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

  • 销售情况
    销售部门要反馈销售情况，畅销就多采购，滞销就不采购。
  • 库存情况
    即使畅销产品，库存都有1000台了，每天才卖出去10台，也就不需要采购了！

销售模块是企业的盈利核心，对其他两个模块也有影响：

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

  • 督促采购
    在特殊情况下，比如一个企业客户要一次性购买100台电脑，库存只有80台，这时需要催促采购部门赶快采购！
    同样的，库存管理也对其他两个模块有影响。库房是有容积限制的，所以就有了清仓处理，那就要求采购部门停止采购，同时销售部门进行打折销售。
    从以上分析来看，这三个模块都有自己的行为，并且与其他模块之间的行为产生关联，类似我们办公一样，各个部门负责不一样，但是彼此之间有交叉，于是彼此之间就产生了紧耦合。我们先来实现这个进销存，类图14-2：


    12-2

    Purchase负责采购管理，buyIBMComputer指定了采购IBM电脑，refuseBuyIBM是指不在采购IBM了，代码如下：

public class Purchase {
    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+"台");
            stock.increase(number);
        }else{//销售情况不好
            number = number/2;
            System.out.println("采购IBM电脑:"+number+"台");
            stock.increase(number);
        }
    }

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

}

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

public class Stock {
    //刚开始有100台电脑
    private static int COMPUTER_NUMBER = 100;
    //库存增加
    public void increase(int number) {
        COMPUTER_NUMBER = COMPUTER_NUMBER + number;
        System.out.println("库存数量为:"+COMPUTER_NUMBER);
    }
    //库存降低
    public void decrease(int number){
        COMPUTER_NUMBER = COMPUTER_NUMBER - number;
        System.out.println("库存数量:"+COMPUTER_NUMBER);
    }
    //获得库存数量
    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电脑
    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 int getSaleStatus() {
        Random rand = new Random(System.currentTimeMillis());
        int saleStatus = rand.nextInt(100);
        System.out.println("IBM电脑的销售情况为："+saleStatus);
        return saleStatus;
    }
    //折价处理
    public void offSale() {
        //库房有多少卖多少
        Stock stock = new Stock();
        System.out.println("折价销售IBM电脑"+stock.getStockNumber()+"台");
    }
}

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

public class Client {
    public static void main(){
        //采购人员采购电脑
        System.out.println("------采购人员采购电脑-----");
        Purchase purchase = new Purchase();
        purchase.buyIBMcomputer(100);
        //销售人员销售电脑
        System.out.println("---销售人员销售电脑---");
        Sale sale = new Sale();
        sale.sellIBMComputer(1);
        //库房管理人员管理库存
        System.out.println("---库存管理人员清理库存---");
        Stock stock = new Stock();
        stock.clearStock();
    }
}

//运行结果
------采购人员采购电脑-----
IBM电脑的销售情况为：90
采购IBM电脑:100台
库存数量为:200
---销售人员销售电脑---
销售IBM电脑1台
库存数量:199
---库存管理人员清理库存---
清理存货数量为:199
折价销售IBM电脑199台
不在采购IBM电脑

我们在场景类中模拟了三种人员的活动：采购人员采购电脑，销售人员销售电脑，库存管理员管理库存。（这个代码只是一个例子，实际基本不会写这样的代码）
三个不同类型的参与者完成了各自的活动。但是这三个类彼此关联，每个类都和其他类产生了关联关系。迪米特法则认为每个类只和朋友类交流，这个朋友类并非越多越好，朋友类越多，耦合性越大，要想修改就得修改一片，这不是面向对象设计所期望的，况且这还仅三个模块的情况，属于比较简单的一个小项目。我们把进销存扩展一下，如图14-3：

14-3

你看这个蜘蛛网的结构，别说编写程序了，看的都头昏眼花了，每个对象都需要和其他几个对象交流，对象越多，每个对象要交流的成本也就越大了，只是维护这些对象的交流就很麻烦了，我们就会发现这个设计是有缺陷的（我们平时写代码分为了dao层和service层，可不可以理解为用了中介者模式的思想，每个dao层的对象是没有直接交流的，都是通过service来完成沟通，并且每一个dao对应的实体对象可以认为就是一个小的模块）
大家都学过网络的基本知识(大学基本课程，当时只知道玩，可以说是没学过，惭愧)，网络拓扑有三种类型：总线型、环形、星型。星型网络拓扑如图14-4：
14-4

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

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

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

public abstract class AbstractMediator {
    protected Purchase purchase;
    protected Sale sale;
    protected Stock stock;
    //构造函数
    public  AbstractMediator(){
        purchase = new Purchase(this);
        sale = new Sale(this);
        stock = new Stock(this);
    }
    //中介者最重要的方法叫做事件方法，处理多个对象之间的关系
    public abstract void execute(String str,Object ...objects);
}

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

public class Mediator extends AbstractMediator {
    @Override
    public void execute(String str, Object... objects) {
        if("purchase.buy".equals(str)){ //采购电脑
            this.buyComputer((Integer)objects[0]);
        }else if("sale.sell".equals(str)){ //销售电脑
            this.sellComputer((Integer)objects[0]);
        }else if("sale.offsell".equals(str)){ //折价销售
            this.offsell();
        }else if("stock.clear".equals(str)){ //清仓处理
            this.clearStock();
        }
    }

    private void offsell(){
        System.out.println("折价销售IBM电脑:"+stock.getStockNumber()+"台");
    }
private void clearStock(){
        super.sale.offSale();
        super.purchase.refuseBuyIBM();
    }


    private void sellComputer(int number) {
       if(super.stock.getStockNumber() < number){ //库存数量不够销售
           super.purchase.buyIBMcomputer(number);
       }
       super.stock.decrease(number);
    }

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

中介者Mediator定义了多个private方法，其目的是处理各个对象之间的依赖关系，就是说把原有一个对象要依赖多个对象的情况移到中介者的private方法中实现。在实际项目中，一般的做法是中介者按照职责进行划分，每个中介者处理一个或多个类似的关联请求。
由于要使用中介者，我们增加一个抽象同事类，三个具体的实现类分别继承该抽象类（其实各个模块负责的东西不一样，应该不会有太多的相似的特点去抽象，这个比较多余），代码如下：

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

采购Purchase类代码如下:

public class Purchase extends AbstractColleague{
    public Purchase(AbstractMediator mediator){
        super(mediator);
    }
    //采购IBM电脑
    public void buyIBMcomputer(int number){
        super.mediator.execute("purchase.buy",number);
    }
    //不在采购IBM电脑
    public void refuseBuyIBM(){
        System.out.println("不再采购IBM电脑");
    }
}

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

public class Stock extends AbstractColleague {
    private static int COMPUTER_NUMBER = 100;
    public Stock(AbstractMediator mediator) {
        super(mediator);
    }
    //库存增加
    public void increase(int number){
        COMPUTER_NUMBER = COMPUTER_NUMBER+number;
        System.out.println("库存数量为:"+COMPUTER_NUMBER);
    }
    //库存降低
    public void decrease(int number){
        COMPUTER_NUMBER = COMPUTER_NUMBER - number;
        System.out.println("库存数量为:"+COMPUTER_NUMBER);
    }
    //获得库存数量
    public int getStockNumber(){
        return COMPUTER_NUMBER;
    }
    //存货压力大了，就要通知采购人员不要采购，销售人员要尽快 销售
    public void clearStock(){
        System.out.println("清理存货数量为:"+COMPUTER_NUMBER);
        super.mediator.execute("stock.clear");
    }
}

销售管理Sale类代码如下:

public class Sale extends AbstractColleague {
    public Sale(AbstractMediator mediator) {
        super(mediator);
    }
    //销售IBM电脑
    public void sellIBMComputer(int number){
        super.mediator.execute("sale.sell",number);
        System.out.println("销售IBM电脑"+number+"台");
    }
    //反馈销售情况，0到100变化，100代表非常畅销
    public int getSaleStatus(){
        Random rand  = new Random(System.currentTimeMillis());
        int saleStatus = rand.nextInt(100);
        System.out.println("IBM电脑的销售情况为："+saleStatus);
        return saleStatus;
    }
    //折价处理
    public void offSale(){
        super.mediator.execute("sale.offsell");
    }

}

修改后的场景类代码如下:

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("---销售人员销售电脑---");
        Sale sale = new Sale(mediator);
        sale.sellIBMComputer(1);
        //库房管理人员管理库存
        System.out.println("---库存管理人员清理库存---");
        Stock stock = new Stock(mediator);
        stock.clearStock();
    }
}

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

  1. 中介者模式的定义

中介者模式的定义为:Define an object that encapsulates how a set of objects interact.Mediator promotes loose coupling by keeping objects from referring to each other explicitly,and it lets you vary their interaction independently.(用一个中介对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使其耦合松散，而且可以独立地改变他们之间的交互。)
中介者模式通用类图如图14-7:

14-7

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

  • Mediator抽象中介者角色
    抽象中介者角色定义统一的接口，用于各同事角色之间的通信。
  • Concrete Mediator 具体中介者角色
    具体中介者角色通过协调各同事角色实现协作行为，因此它必须依赖于各个同色角色。
  • Colleague同事角色
    每一个同事角色都知道中介者角色，而且与其他的同事角色通信的时候，一定要通过中介者角色协作。每个同事类的行为分为两种：一种是同事本身的行为，比如改变对象本身的状态，处理自己的行为等，这种行为叫做自发行为（Self-Method），与其他的同事类或中介者没有任何的依赖；第二种是必须依赖中介者才能完成的行为，叫做依赖方法（DepMethod）。
    中介者模式比较简单，其通用源码也比较简单，先看抽象中介者Mediator类，代码如下:
//定义同事类
    protected ConcreteColleague1 c1;
    protected ConcreteColleague2 c2;

    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.selfMethod1();
    }

    @Override
    public void dosomething2() {
        //调用同事类的方法，只要public方法调用
        super.c1.selfMethod1();
        super.c2.selfMethod1();
    }
}

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

public class ConcreteColleague1 extends Colleague {
    public ConcreteColleague1(Mediator mediator) {
        super(mediator);
    }
    //自由方法self-method
    public void selfMethod1(){
        //处理自己的业务逻辑
    }
    //依赖方法dep-Method1
    public void depMethod1(){
        //处理自己的业务逻辑
        //自己不能处理的业务逻辑，委托给中介者出来
        super.mediator.dosomething1();
    }
}
public class ConcreteColleague2 extends Colleague {
    public ConcreteColleague2(Mediator mediator) {
        super(mediator);
    }
    //自由方法self-method
    public void selfMethod1(){
        //处理自己的业务逻辑
    }
    //依赖方法dep-Method1
    public void depMethod1(){
        //处理自己的业务逻辑
        //自己不能处理的业务逻辑，委托给中介者出来
        super.mediator.dosomething1();
    }
}

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

  1. 中介者模式的优点

3.1 中介者模式的优点
中介者模式的优点就是减少类间的依赖，把原有的一对多的依赖变成一对一的依赖，同事类只依赖中介者，减少了依赖，当然同事也降低类间的耦合。
3.2 中介者模式的缺点
中介者模式的缺点就是中介者会膨胀的很大，而且逻辑复杂，原本N个对象直接的相互依赖关系转换为中介者和同事类的依赖关系，同事类越多，中介者的逻辑就越复杂。
3.3中介者模式的使用场景
中介者模式简单，但是简单不代表容易使用，和容易被误用。在面向对象编程中，对象和对象之间必然会有依赖关系，如果么个类和其他类没有相互依赖的关系，那这个类在项目中也没有存在的必要了！类之间的依赖关系是必然存在的，一个类依赖多个类的情况也是存在的，存在即合理，那么是否可以说只要有多个依赖关系就考虑使用中介者模式呢？不用想，肯定不对，我们一直强调没有什么原则是一定得，都是看情况活用，我们要合理的使用可以帮我们理清原本复杂的类依赖关系。典型例子就是上面蜘蛛网结构整理成星型结构。

  1. 中介者模式的实际应用

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

  • 机场调度中心
    调度中心控制飞机啥时候起飞和降落，就是调度中心将各个飞机的起落顺序控制好
  • MVC框架
    controller就是一个中介者将v（view，视图）和M(Model,业务逻辑)隔离开，协调M和V协同工作。
  • 媒体网关
  • 中介服务
    （艺术来源生活，高于生活；这里也可以说，设计也是来源于生活）
  1. 最佳实践
  • N个对象之间产生了相互的依赖的关系（N>2）；
  • 多个对象有依赖关系，但是依赖的行为尚不确定或者有发生改变的可能，在这种情况下一般建议采用中介者模式，降低变更引起的风险；
  • 产品开发。一个明显的例子就是MVC框架。

内容来自《设计模式之禅》

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 213,752评论 6赞 493
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 91,100评论 3赞 387
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 159,244评论 0赞 349
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 57,099评论 1赞 286
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 66,210评论 6赞 385
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 50,307评论 1赞 292
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 39,346评论 3赞 412
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 38,133评论 0赞 269
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 44,546评论 1赞 306
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,849评论 2赞 328
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,019评论 1赞 341
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 34,702评论 4赞 337
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 40,331评论 3赞 319
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,030评论 0赞 21
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,260评论 1赞 267
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 46,871评论 2赞 365
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 43,898评论 2赞 351