中介者模式

Published on 2016 - 07 - 14

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

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

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

  • 销售情况

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

  • 库存情况

即使是畅销产品,库存都有1000台了,每天才卖出去10台,也就不需要再采购了!

销售模块是企业的赢利核心,对其他两个模块也有影响:

  • 库存情况

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

  • 督促采购

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

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

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

Purchase负责采购管理,buyIBMComputer指定了采购IBM电脑,refuseBuyIBM是指不再采购IBM了,源代码如代码清单1所示。

public class Purchase {
     //采购IBM电脑
     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{  //销售情况不好
                     int buyNumber = number/2;  //折半采购
                     System.out.println("采购IBM电脑:"+buyNumber+ "台");
             }
     }  
     //不再采购IBM电脑
     public void refuseBuyIBM(){
             System.out.println("不再采购IBM电脑");
     }
}

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

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;
     }
w //存货压力大了,就要通知采购人员不要采购,销售人员要尽快销售
     public void clearStock(){
             Purchase purchase = new Purchase();
             Sale sale = new Sale();
             System.out.println("清理存货数量为:"+COMPUTER_NUMBER);
             //要求折价销售
             sale.offSale();
             //要求采购人员不要采购
             purchase.refuseBuyIBM();
     }
}

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

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);
     }
     //反馈销售情况,0~100之间变化,0代表根本就没人卖,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(){
             //库房有多少卖多少
             Stock stock = new Stock();
             System.out.println("折价销售IBM电脑"+stock.getStockNumber()+"台");
     }
}

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

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电脑的销售情况为:95
采购IBM电脑:100台
库存数量为:200
------销售人员销售电脑--------
销售IBM电脑1台
库存数量为:199
------库房管理人员清库处理--------
清理存货数量为:199
折价销售IBM电脑199台
不再采购IBM电脑

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

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

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

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

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

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

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);
}

再来看具体的中介者,我们可以根据业务的要求产生多个中介者,并划分各中介者的职责。具体中介者如代码清单6所示。

public class Mediator extends AbstractMediator {
     //中介者最重要的方法
     public void execute(String str,Object...objects){
             if(str.equals("purchase.buy")){ //采购电脑
                    this.buyComputer((Integer)objects[0]);
             }else if(str.equals("sale.sell")){ //销售电脑
                    this.sellComputer((Integer)objects[0]);
             }else if(str.equals("sale.offsell")){ //折价销售
                    this.offSell();
             }else if(str.equals("stock.clear")){ //清仓处理
                    this.clearStock();
             }
     }
     //采购电脑
     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+ "台");
             }
     }
     //销售电脑
     private void sellComputer(int number){
             if(super.stock.getStockNumber()<number){  //库存数量不够销售
                    super.purchase.buyIBMcomputer(number);
             }
             super.stock.decrease(number);
     }
     //折价销售电脑
     private void offSell(){
             System.out.println("折价销售IBM电脑"+stock.getStockNumber()+"台");
     }
     //清仓处理
     private void clearStock(){
             //要求清仓销售
             super.sale.offSale();
             //要求采购人员不要采购
             super.purchase.refuseBuyIBM();
     }
}

中介者Mediator定义了多个private方法,其目的是处理各个对象之间的依赖关系,就是说把原有一个对象要依赖多个对象的情况移到中介者的private方法中实现。在实际项目中,一般的做法是中介者按照职责进行划分,每个中介者处理一个或多个类似的关联请求。

由于要使用中介者,我们增加了一个抽象同事类,三个具体的实现类分别继承该抽象类,如代码清单7所示。

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

采购Purchase类如代码清单8所示

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类,如代码清单9所示。

public class Stock extends AbstractColleague {
     public Stock(AbstractMediator _mediator){
             super(_mediator);
     }
     //刚开始有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(){
             System.out.println("清理存货数量为:"+COMPUTER_NUMBER);
             super.mediator.execute("stock.clear");
     }
}

销售管理Sale类如代码清单10所示。

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变化,0代表根本就没人买,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");
     }
}

增加了中介者,场景类也需要小小的改动,如代码清单11所示。

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

在场景类中增加了一个中介者,然后分别传递到三个同事类中,三个类都具有相同的特性:只负责处理自己的活动(行为),与自己无关的活动就丢给中介者处理,程序运行的结果是相同的。从项目设计上来看,加入了中介者,设计结构清晰了很多,而且类间的耦合性大大减少,代码质量也有了很大的提升。

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

中介者模式的定义

中介者模式的定义为: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.(用一个中介对象封装一系列的对象交互,中介者使各对象不需要显示地相互作用,从而使其耦合松散,而且可以独立地改变它们之间的交互。)

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

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

  • Mediator 抽象中介者角色

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

  • Concrete Mediator 具体中介者角色

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

  • Colleague 同事角色

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

中介者模式比较简单,其通用源码也比较简单,先看抽象中介者Mediator类,如代码清单12所示。

public abstract class Mediator {
     //定义同事类
     protected ConcreteColleague1 c1;
     protected ConcreteColleague2 c2;
     //通过getter/setter方法把同事类注入进来
     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等,那当然注入抽象类,做到依赖倒置。

具体的中介者一般只有一个,即通用中介者,其源代码如代码清单13所示。

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

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

同事类的基类如代码清单14所示。

public abstract class Colleague {
     protected Mediator mediator;
     public Colleague(Mediator _mediator){
             this.mediator = _mediator;
     }
}

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

public class ConcreteColleague1 extends Colleague {
     //通过构造函数传递中介者
     public ConcreteColleague1(Mediator _mediator){
             super(_mediator);
     }
     //自有方法 self-method
     public void selfMethod1(){
             //处理自己的业务逻辑
     }
     //依赖方法 dep-method
     public void depMethod1(){
             //处理自己的业务逻辑
             //自己不能处理的业务逻辑,委托给中介者处理
             super.mediator.doSomething1();
     }
}
public class ConcreteColleague2 extends Colleague {
     //通过构造函数传递中介者
     public ConcreteColleague2(Mediator _mediator){
             super(_mediator);
     }
     //自有方法 self-method
     public void selfMethod2(){
             //处理自己的业务逻辑
     }
     //依赖方法 dep-method
     public void depMethod2(){
             //处理自己的业务逻辑
             //自己不能处理的业务逻辑,委托给中介者处理
             super.mediator.doSomething2();
     }
}

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

中介者模式的应用

中介者模式的优点

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

中介者模式的缺点

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

中介者模式的使用场景

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

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

中介者模式的实际应用

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

机场调度中心

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

MVC框架

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

媒体网关

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

中介服务

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

最佳实践

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

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

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

参考文档