23種設(shè)計(jì)模式-中介者模式

  1. 進(jìn)銷存管理是這個樣子的嗎

書中通過各個公司的基本模式來引入這個模式，無論是哪個公司都有相同的三個環(huán)節(jié)：采購、銷售和庫存（這里不單單是指實(shí)際存在的產(chǎn)品，也包括一些沒有實(shí)質(zhì)的知識），確實(shí)也是這樣，不管是哪個行業(yè)，都少不了這三個環(huán)節(jié)，做產(chǎn)品的不提，哪怕是做咨詢服務(wù)的公司，他也要采購知識經(jīng)驗(yàn)，這是這類企業(yè)的生存之本，銷售的也是知識和經(jīng)驗(yàn)，庫存同樣是知識和經(jīng)驗(yàn)。既然進(jìn)銷存是如此重要，我們今天就來學(xué)學(xué)它的原理和設(shè)計(jì)，三個模塊的示意圖如圖14-1：

14-1

我們可以從示意圖上看出，這三個模塊是相互依賴的。我們以一個終端銷售商（以服務(wù)最終客戶為目標(biāo)的企業(yè)，比如某某超市、某某商店等）為例，采購部門要采購IBM的電腦，他根據(jù)以下兩個要素來決定采購數(shù)量。

  • 銷售情況
    銷售部門要反饋銷售情況，暢銷就多采購，滯銷就不采購。
  • 庫存情況
    即使暢銷產(chǎn)品，庫存都有1000臺了，每天才賣出去10臺，也就不需要采購了！

銷售模塊是企業(yè)的盈利核心，對其他兩個模塊也有影響：

  • 庫存情況
    庫房有貨，才能銷售，空手套白狼是不行的。

  • 督促采購
    在特殊情況下，比如一個企業(yè)客戶要一次性購買100臺電腦，庫存只有80臺，這時需要催促采購部門趕快采購！
    同樣的，庫存管理也對其他兩個模塊有影響。庫房是有容積限制的，所以就有了清倉處理，那就要求采購部門停止采購，同時銷售部門進(jìn)行打折銷售。
    從以上分析來看，這三個模塊都有自己的行為，并且與其他模塊之間的行為產(chǎn)生關(guān)聯(lián)，類似我們辦公一樣，各個部門負(fù)責(zé)不一樣，但是彼此之間有交叉，于是彼此之間就產(chǎn)生了緊耦合。我們先來實(shí)現(xiàn)這個進(jìn)銷存，類圖14-2：


    12-2

    Purchase負(fù)責(zé)采購管理，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定義了采購電腦的標(biāo)準(zhǔn)：如果銷售情況比較好，大于80分，你讓我采購多少我就采購多少；銷售情況不好，你讓我采購100臺，我就采購50臺，對折采購。電腦采購?fù)戤?，需要放到庫房中，因此要調(diào)用庫存的方法，增加庫存電腦數(shù)量。我們繼續(xù)來看庫存Stock類，代碼如下：

public class Stock {
    //剛開始有100臺電腦
    private static int COMPUTER_NUMBER = 100;
    //庫存增加
    public void increase(int number) {
        COMPUTER_NUMBER = COMPUTER_NUMBER + number;
        System.out.println("庫存數(shù)量為:"+COMPUTER_NUMBER);
    }
    //庫存降低
    public void decrease(int number){
        COMPUTER_NUMBER = COMPUTER_NUMBER - number;
        System.out.println("庫存數(shù)量:"+COMPUTER_NUMBER);
    }
    //獲得庫存數(shù)量
    public int getStockNumber(){
        return COMPUTER_NUMBER;
    }
    //存貨壓力大了，就要通知采購人員不要采購了，銷售人員要盡快銷售
    public void clearStock(){
        Purchase purchase = new Purchase();
        Sale sale = new Sale();
        System.out.println("清理存貨數(shù)量為:"+COMPUTER_NUMBER);
        //要求折價銷售
        sale.offSale();
        //要求采購人員不要采購
        purchase.refuseBuyIBM();
    }
}

庫存中的貨物數(shù)量肯定有增減，同時庫存中還有一個容量顯示，達(dá)到一定得容量后就要求對一些商品進(jìn)行折價處理，以騰出更多的空間容納新產(chǎn)品。于是就有了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){ //庫存數(shù)量不夠
            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是獲得銷售情況，這個當(dāng)然要出現(xiàn)在Sale類中了。記住要把恰當(dāng)?shù)念惙诺角‘?dāng)?shù)念愔?，銷售情況只有銷售人員才能反饋出來，通過百分制的機(jī)制衡量銷售情況。我們在看看場景類是怎么運(yùn)行的，代碼如下：

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

//運(yùn)行結(jié)果
------采購人員采購電腦-----
IBM電腦的銷售情況為：90
采購IBM電腦:100臺
庫存數(shù)量為:200
---銷售人員銷售電腦---
銷售IBM電腦1臺
庫存數(shù)量:199
---庫存管理人員清理庫存---
清理存貨數(shù)量為:199
折價銷售IBM電腦199臺
不在采購IBM電腦

我們在場景類中模擬了三種人員的活動：采購人員采購電腦，銷售人員銷售電腦，庫存管理員管理庫存。（這個代碼只是一個例子，實(shí)際基本不會寫這樣的代碼）
三個不同類型的參與者完成了各自的活動。但是這三個類彼此關(guān)聯(lián)，每個類都和其他類產(chǎn)生了關(guān)聯(lián)關(guān)系。迪米特法則認(rèn)為每個類只和朋友類交流，這個朋友類并非越多越好，朋友類越多，耦合性越大，要想修改就得修改一片，這不是面向?qū)ο笤O(shè)計(jì)所期望的，況且這還僅三個模塊的情況，屬于比較簡單的一個小項(xiàng)目。我們把進(jìn)銷存擴(kuò)展一下，如圖14-3：

14-3

你看這個蜘蛛網(wǎng)的結(jié)構(gòu)，別說編寫程序了，看的都頭昏眼花了，每個對象都需要和其他幾個對象交流，對象越多，每個對象要交流的成本也就越大了，只是維護(hù)這些對象的交流就很麻煩了，我們就會發(fā)現(xiàn)這個設(shè)計(jì)是有缺陷的（我們平時寫代碼分為了dao層和service層，可不可以理解為用了中介者模式的思想，每個dao層的對象是沒有直接交流的，都是通過service來完成溝通，并且每一個dao對應(yīng)的實(shí)體對象可以認(rèn)為就是一個小的模塊）
大家都學(xué)過網(wǎng)絡(luò)的基本知識(大學(xué)基本課程，當(dāng)時只知道玩，可以說是沒學(xué)過，慚愧)，網(wǎng)絡(luò)拓?fù)溆腥N類型：總線型、環(huán)形、星型。星型網(wǎng)絡(luò)拓?fù)淙鐖D14-4：
14-4

在星型網(wǎng)絡(luò)拓?fù)渲?，每個計(jì)算機(jī)通過交換機(jī)和其他計(jì)算機(jī)進(jìn)行數(shù)據(jù)交換，各個計(jì)算機(jī)之間并沒有直接出現(xiàn)交互情況。這種結(jié)構(gòu)簡單，而且穩(wěn)定，只要中間那個交換機(jī)不癱瘓，網(wǎng)絡(luò)就不會發(fā)生大的故障。公司和網(wǎng)吧一般都是采用星型網(wǎng)絡(luò)。我們把這種星型結(jié)構(gòu)引入到我們的設(shè)計(jì)中，示意圖14-5：
14-5

加入一個中介者作為三個模塊的交流核心，每個模塊之間不再互相交流，只通過中介者交流。每個模塊只負(fù)責(zé)自己的業(yè)務(wù)邏輯，不屬于自己的則丟個中介者來處理，簡化了各個模塊之間的耦合關(guān)系，類圖14-6：
14-6

建立了兩個抽象類AbstractMediator和AbstractColeague，每個對象只是與中介者M(jìn)ediator之間產(chǎn)生依賴，與其他對象之間沒有直接關(guān)系，AbstractMediator的作用是實(shí)現(xiàn)中介者的抽象定義，定義了一個抽象方法execute，代碼如下：

public abstract class AbstractMediator {
    protected Purchase purchase;
    protected Sale sale;
    protected Stock stock;
    //構(gòu)造函數(shù)
    public  AbstractMediator(){
        purchase = new Purchase(this);
        sale = new Sale(this);
        stock = new Stock(this);
    }
    //中介者最重要的方法叫做事件方法，處理多個對象之間的關(guān)系
    public abstract void execute(String str,Object ...objects);
}

再來看看具體的中介者，我們可以根據(jù)業(yè)務(wù)的要求產(chǎn)生多個中介者，并劃分各個中介者的職責(zé)，具體中介者的代碼如下:

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){ //庫存數(shù)量不夠銷售
           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);
        }
    }
}

中介者M(jìn)ediator定義了多個private方法，其目的是處理各個對象之間的依賴關(guān)系，就是說把原有一個對象要依賴多個對象的情況移到中介者的private方法中實(shí)現(xiàn)。在實(shí)際項(xiàng)目中，一般的做法是中介者按照職責(zé)進(jìn)行劃分，每個中介者處理一個或多個類似的關(guān)聯(lián)請求。
由于要使用中介者，我們增加一個抽象同事類，三個具體的實(shí)現(xiàn)類分別繼承該抽象類（其實(shí)各個模塊負(fù)責(zé)的東西不一樣，應(yīng)該不會有太多的相似的特點(diǎn)去抽象，這個比較多余），代碼如下：

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類簡化了很多，處理自己的職責(zé)，與外界有關(guān)系的事件處理則交給中介者來完成。再來看看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("庫存數(shù)量為:"+COMPUTER_NUMBER);
    }
    //庫存降低
    public void decrease(int number){
        COMPUTER_NUMBER = COMPUTER_NUMBER - number;
        System.out.println("庫存數(shù)量為:"+COMPUTER_NUMBER);
    }
    //獲得庫存數(shù)量
    public int getStockNumber(){
        return COMPUTER_NUMBER;
    }
    //存貨壓力大了，就要通知采購人員不要采購，銷售人員要盡快 銷售
    public void clearStock(){
        System.out.println("清理存貨數(shù)量為:"+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();
    }
}

在場景類中增加了一個中介者，然后分別傳遞到三個同事類中，三個類都具有相同的特性：只負(fù)責(zé)處理自己的活動，與自己無關(guān)的活動就丟給中介者處理，程序運(yùn)行的結(jié)果是相同的。從項(xiàng)目設(shè)計(jì)上看，加入了中介者，設(shè)計(jì)結(jié)構(gòu)清晰了很多，而且類間的耦合性大大減少了，代碼質(zhì)量也有了很大的提升。
在多個對象依賴的情況下，通過加入中介者角色，取消了多個對象的關(guān)聯(lián)或依賴關(guān)系，減少了對象的耦合性。

  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.(用一個中介對象封裝一系列的對象交互，中介者使各對象不需要顯示地相互作用，從而使其耦合松散，而且可以獨(dú)立地改變他們之間的交互。)
中介者模式通用類圖如圖14-7:

14-7

從類圖中看，中介者模式由以下幾部分組成：

  • Mediator抽象中介者角色
    抽象中介者角色定義統(tǒng)一的接口，用于各同事角色之間的通信。
  • Concrete Mediator 具體中介者角色
    具體中介者角色通過協(xié)調(diào)各同事角色實(shí)現(xiàn)協(xié)作行為，因此它必須依賴于各個同色角色。
  • Colleague同事角色
    每一個同事角色都知道中介者角色，而且與其他的同事角色通信的時候，一定要通過中介者角色協(xié)作。每個同事類的行為分為兩種：一種是同事本身的行為，比如改變對象本身的狀態(tài)，處理自己的行為等，這種行為叫做自發(fā)行為（Self-Method），與其他的同事類或中介者沒有任何的依賴；第二種是必須依賴中介者才能完成的行為，叫做依賴方法（DepMethod）。
    中介者模式比較簡單，其通用源碼也比較簡單，先看抽象中介者M(jìn)ediator類，代碼如下:
//定義同事類
    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;
    }

    //中介者模式的業(yè)務(wù)邏輯
    public abstract void dosomething1();
    public abstract void dosomething2();

在Mediator抽象類中我們只定義了同事類的注入，為什么使用同類實(shí)現(xiàn)類注入而不使用抽象類注入呢？那是因?yàn)橥骂愲m然有抽象，但是沒有每個同事類必須完成的業(yè)務(wù)方法，當(dāng)然如果每個同事類都用相同的方法，比如execute、handler等，那當(dāng)然注入抽象類，做到依賴倒置。
具體的中介者一般只有一個，即通用中介者，其源代碼如下：

public class ConcreteMediator extends Mediator {
    @Override
    public void dosomething1() {
        //調(diào)用同事類的方法，只要public方法調(diào)用
        super.c1.selfMethod1();
        super.c2.selfMethod1();
    }

    @Override
    public void dosomething2() {
        //調(diào)用同事類的方法，只要public方法調(diào)用
        super.c1.selfMethod1();
        super.c2.selfMethod1();
    }
}

這個基類也非常簡單。一般來說，中介者模式中的抽象都比較簡單，是為了建立這個中介而服務(wù)的，具體同事類代碼如下:

public class ConcreteColleague1 extends Colleague {
    public ConcreteColleague1(Mediator mediator) {
        super(mediator);
    }
    //自由方法self-method
    public void selfMethod1(){
        //處理自己的業(yè)務(wù)邏輯
    }
    //依賴方法dep-Method1
    public void depMethod1(){
        //處理自己的業(yè)務(wù)邏輯
        //自己不能處理的業(yè)務(wù)邏輯，委托給中介者出來
        super.mediator.dosomething1();
    }
}
public class ConcreteColleague2 extends Colleague {
    public ConcreteColleague2(Mediator mediator) {
        super(mediator);
    }
    //自由方法self-method
    public void selfMethod1(){
        //處理自己的業(yè)務(wù)邏輯
    }
    //依賴方法dep-Method1
    public void depMethod1(){
        //處理自己的業(yè)務(wù)邏輯
        //自己不能處理的業(yè)務(wù)邏輯，委托給中介者出來
        super.mediator.dosomething1();
    }
}

為什么同事類要使用構(gòu)造函數(shù)注入中介者，而中介者使用getter/setter
方式注入同事類呢？因?yàn)橥骂惐仨氂芍薪檎?，而中介者卻可以只有部分同事類。

  1. 中介者模式的優(yōu)點(diǎn)

3.1 中介者模式的優(yōu)點(diǎn)
中介者模式的優(yōu)點(diǎn)就是減少類間的依賴，把原有的一對多的依賴變成一對一的依賴，同事類只依賴中介者，減少了依賴，當(dāng)然同事也降低類間的耦合。
3.2 中介者模式的缺點(diǎn)
中介者模式的缺點(diǎn)就是中介者會膨脹的很大，而且邏輯復(fù)雜，原本N個對象直接的相互依賴關(guān)系轉(zhuǎn)換為中介者和同事類的依賴關(guān)系，同事類越多，中介者的邏輯就越復(fù)雜。
3.3中介者模式的使用場景
中介者模式簡單，但是簡單不代表容易使用，和容易被誤用。在面向?qū)ο缶幊讨?，對象和對象之間必然會有依賴關(guān)系，如果么個類和其他類沒有相互依賴的關(guān)系，那這個類在項(xiàng)目中也沒有存在的必要了！類之間的依賴關(guān)系是必然存在的，一個類依賴多個類的情況也是存在的，存在即合理，那么是否可以說只要有多個依賴關(guān)系就考慮使用中介者模式呢？不用想，肯定不對，我們一直強(qiáng)調(diào)沒有什么原則是一定得，都是看情況活用，我們要合理的使用可以幫我們理清原本復(fù)雜的類依賴關(guān)系。典型例子就是上面蜘蛛網(wǎng)結(jié)構(gòu)整理成星型結(jié)構(gòu)。

  1. 中介者模式的實(shí)際應(yīng)用

中介者模式也叫作調(diào)停者模式，一個對象要和N個對象交流，就像對象間的戰(zhàn)爭，很混亂。這時，需要加入一個中心，所有的類都和中心交流，中心說怎么處理就怎么處理，我們舉一些開發(fā)和生活中經(jīng)常會碰到的例子。

  • 機(jī)場調(diào)度中心
    調(diào)度中心控制飛機(jī)啥時候起飛和降落，就是調(diào)度中心將各個飛機(jī)的起落順序控制好
  • MVC框架
    controller就是一個中介者將v（view，視圖）和M(Model,業(yè)務(wù)邏輯)隔離開，協(xié)調(diào)M和V協(xié)同工作。
  • 媒體網(wǎng)關(guān)
  • 中介服務(wù)
    （藝術(shù)來源生活，高于生活；這里也可以說，設(shè)計(jì)也是來源于生活）
  1. 最佳實(shí)踐
  • N個對象之間產(chǎn)生了相互的依賴的關(guān)系（N>2）；
  • 多個對象有依賴關(guān)系，但是依賴的行為尚不確定或者有發(fā)生改變的可能，在這種情況下一般建議采用中介者模式，降低變更引起的風(fēng)險；
  • 產(chǎn)品開發(fā)。一個明顯的例子就是MVC框架。

內(nèi)容來自《設(shè)計(jì)模式之禪》

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

友情鏈接更多精彩內(nèi)容