設計模式 | 橋接模式（bridge）

莫愆發表於2020-10-24
設計模式橋接

定義：

將抽象部分與它的實現部分分離，使它們都可以獨立地變化

結構：（書中圖，侵刪）

 

一個抽象類，用於聚合實現
若干個實現抽象類的類
一個實現的父類
若干個實現了父類的具體實現類

例項：

我想到了一個工作中的例子，通常我們需要去對接一些第三方平臺。
假如最開始你需要對接淘寶平臺，去建立銷售單。然後過段時間又需要去對接京東平臺，也是要建立銷售單。
你的類結構大概是這樣的：

 

出於物件導向考慮，你可能會給平臺加個父類，變成這樣：

 

這時候又告訴你，你需要給兩個平臺都新增獲取訂單的功能，然後變成這樣：

 

假設接下來又要給每個平臺新增建立退貨單，抓取退貨單，然後又新加了兩個平臺，amazon，ebay什麼的。
那簡直就是災難。程式碼沒法複用，複製貼上可不算複用，雖然每個平臺都會有些不一樣，但是功能本身是大同小異的。
於是呢，就引出了我們的橋接模式，按照我的理解來說，就是將系統按照各個維度拆分出來，每個維度都是獨立的部分，互不影響，同時通過一座橋（這裡指聚合，後面會細講）把他們連線起來。
修改之後的類結構是這樣：

 

操作父類：

package designpattern.bridge;

public abstract class Operation {
    public abstract void operate();
}

建立訂單類：

package designpattern.bridge;

public class CreateOrder extends Operation {
    @Override
    public void operate() {
        System.out.println("建立訂單");
    }
}

獲取訂單類：

package designpattern.bridge;

public class GetOrders extends Operation {
    @Override
    public void operate() {
        System.out.println("獲取訂單");
    }
}

平臺父類（聚合類）：

package designpattern.bridge;

public abstract class Platform {
    protected Operation operation;

    public void setOperation(Operation operation) {
        this.operation = operation;
    }

    public abstract void operate();
}

淘寶類：

package designpattern.bridge;

public class Taobao extends Platform {
    @Override
    public void operate() {
        System.out.print("淘寶->");
        operation.operate();
    }
}

京東類：

package designpattern.bridge;

public class JingDong extends Platform {
    @Override
    public void operate() {
        System.out.print("京東->");
        operation.operate();
    }
}

客戶端：

package designpattern.bridge;

public class Client {
    public static void main(String[] args) {
        Operation createOrder=new CreateOrder();
        Operation getOrder=new GetOrders();
        
        Platform tb=new Taobao();
        tb.setOperation(createOrder);
        tb.operate();
        tb.setOperation(getOrder);
        tb.operate();
        
        System.out.println("==============================");
        
        Platform jd=new JingDong();
        jd.setOperation(createOrder);
        jd.operate();
        jd.setOperation(getOrder);
        jd.operate();
    }
}

結果輸出：

淘寶->建立訂單
淘寶->獲取訂單
==============================
京東->建立訂單
京東->獲取訂單

 

 番外：

書中還提到一個原則：

 

然後在《effective java》這本書也看到了類似的內容，角度又有些不同：

 

大概說的是，子類必須依附於父類，如果父類修改了，子類必須得跟著一起改。甚至父類新增了一個和子類簽名相同，但是返回型別不同的方法，會導致你的編譯不通過。
解決方法，就是複合，也是上面說的合成-》新類不繼承父類，而是包含一個擁有父類（雖然沒有繼承，為了前後統一，還是稱之為父類）例項的域，通過這個例項去訪問父類的方法。
上文提到的包裝類是指的裝飾模式（decorator），這裡就不展開了，感興趣的可以看看之前寫的文章：設計模式 | 裝飾模式（decorator）

總結：

核心還是解耦，以及開放-封閉原則。要想方設法的讓新增功能的時候不影響之前的程式碼。設計模式只是表現形式不一樣，核心都差不多。
橋接模式在系統出現多維度的時候就可以考慮使用，其實這種是在最開始就能預見到的，比如文中舉的例子，通常都能想到未來可能增加功能和平臺，所以在寫第一個平臺的第一個功能的時候就應該有意識的去設計。（哈哈哈，打臉來得總是這麼的觸不及防，剛說要提前去設計，就在下一章看見了文尾圖中的內容）
最後就是在使用繼承前要再三的確認是不是“is a”關係，即便是也不要輕易的使用繼承，複合往往是更優先的選擇。

 

 

 關於上圖說的命令模式，可見：設計模式 | 命令模式（Command）

 

 

相關文章