首页 » 设计模式之禅(第2版) » 设计模式之禅(第2版)全文在线阅读

《设计模式之禅(第2版)》第14章 中介者模式

关灯直达底部

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

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

图14-1 进销存示意图

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

● 销售情况

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

● 库存情况

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

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

● 库存情况

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

● 督促采购

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

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

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

图14-2 简单的进销存类图

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

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

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

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

代码清单14-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类中了。记住要把恰当的类放到恰当的类中,销售情况只有销售人员才能反馈出来,通过百分制的机制衡量销售情况。我们再来看场景类是怎么运行的,场景类如代码清单14-4所示。

代码清单14-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电脑

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

图14-3 扩展后的进销存示意图

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

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

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

图14-4 星型网络拓扑

图14-5 修改后的进销存示意图

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

图14-6 修改后的进销存类图

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

代码清单14-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);} 

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

代码清单14-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方法中实现。在实际项目中,一般的做法是中介者按照职责进行划分,每个中介者处理一个或多个类似的关联请求。

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

代码清单14-7 抽象同事类

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

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

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

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

代码清单14-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/");     }}  

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

代码清单14-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;     }} 

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

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