【淺談設計模式】(9):橋接模式--由「手抓餅案例」再次入門

前言

本週的學習計劃包括這篇設計模式了。離上次更文也隔了半個多月了，發現設計模式的學習之路自己是一件挺枯燥的事情，可是若是能用一種有趣的方式將出來，我以爲是很厲害的，所以，我在學習的同時也但願可以以更通俗的語言來說解這些東西。編程

今天要學的講的內容是結構型模式的第四種----橋接模式。設計模式

1、橋接模式入門

1.1 概述

橋接模式的問題經常用來解決多個維度的問題。好比這張經典的圖，河一邊是電腦、電視、收音機等設備，而河對岸是各類遙控器，這其實對應兩個維度，經過一架高橋完成鏈接通訊。而所謂的「橋」的聯繫是提取出來的接口的聯繫，在維度一中調用維度二的接口，而後把接口傳入維度一的構造方法中。markdown

下面咱們繼續以淺談裝飾者模式中的手抓餅案例爲例，來開始橋接模式的講解。架構

假設賣手抓餅的大娘目前的業務有山東雜糧煎餅、原味手抓餅。如今爲了擴大銷量，採用了線下店鋪和淘寶電商的多種渠道方式，這就是包括售賣產品和售賣渠道的兩種維度。post

可是這種定義明顯有着一個缺點，就是每增長一種售賣產品，可能相應的就多了好多種售賣渠道的產品，一樣的每多一種售賣渠道，就多好多種售賣產品的渠道。不管增長哪一維度，都須要建立更多的類，所以，在一個多種可能會變化的維度的系統中，用繼承會形成類爆炸，不靈活，每次在一個維度上新增一個具體實現，都須要增長多個子類，此時就能夠考慮橋接模式。學習

橋接模式（Bridge patten），是結構型設計模式的一種，它能夠將一個大類或一系列緊密相關的類拆分爲抽象和實現兩個獨立的層次結構，從而能夠在開發時分別使用。this

引用百度百科定義：spa

將抽象部分與它的實現部分分離，使它們均可以獨立的變化。設計

百度百科的定義相對難懂，咱們只須要記住橋接模式的特色將抽象和實現分離，在抽象層創建依賴，從而兩個維度上的實現類能夠進行各自的變化而不會相互影響，具備很是好的擴展性。3d

1.2 橋接模式結構

橋接模式包含如下角色：

抽象化角色：定義抽象類，幷包含一個對實現化對象的引用。
擴展抽象化角色：是抽象化角色的子類，實現父類中的業務方法，並經過組合關係調用實現化角色中的業務方法。
實現化角色：定義實現化角色的接口，供擴展抽象化角色調用
具體實現化角色：給出實現化角色接口的具體實現。

2、案例講解

下面，咱們開始對前面將的案例進行 demo 還原。

實現化角色：

/**
 * 售賣方式
 * @Author xiaolei
 * @Date 2021/7/17 16:02
 **/
public interface SaleModel {
    void sale(String product);
}
複製代碼

線下店鋪售賣 --- 具體實現化角色：

public class OfflineSafe implements SaleModel {
    public void sale(String product) {
        System.out.println("線下店鋪售賣:"+product);
    }
}
複製代碼

線上淘寶售賣 --- 具體實現化角色

public class TaoBaoSafe implements SaleModel {
    public void sale(String product) {
        System.out.println("淘寶電商售賣："+product);
    }
}
複製代碼

產品類：

/**
 * 售賣產品
 **/
public abstract class Product {
    protected SaleModel saleModel;
    public Product(SaleModel saleModel){
        this.saleModel=saleModel;
    }
    public abstract void make(String name);
}

複製代碼

手抓餅 -- （抽象化角色子類）

public class HandPancke extends Product {

    public HandPancke(SaleModel saleModel) {
        super(saleModel);
    }

    public void make(String name) {
        saleModel.sale(name);
    }
}
複製代碼

山東雜糧煎餅類 --（抽象化角色子類）

public class ShandongPancake extends Product {
    public ShandongPancake(SaleModel saleModel) {
        super(saleModel);
    }

    public void make(String name) {
        saleModel.sale(name);
    }
}
複製代碼

輸出結果：

3、總結

3.1 優缺點

3.1.1 優勢

抽象和實現分離：這是橋接模式的主要特色，也是避免使用繼承的主要緣由。使用橋接模式，解耦了抽象和實現，使得二者的變化不會對另外一方產生影響，使得系統擴展性大大加強。
優秀的擴展能力：橋接模式的出現是爲了解決多個獨立變化的維度的耦合，其高層模塊聚合關係已肯定，所以，不管是抽象變化仍是實現變化，只要對其進行擴展便可，高層代碼無序更改，嚴格遵照了依賴倒置原則。
實現細節對客戶透明：因爲橋接模式在高層模塊中經過聚合關係構建了穩定的架構（封裝）。所以，客戶只需與高層模塊交互，對抽象和實現的細節徹底不需關注。

3.1.2 缺點

橋接模式因爲聚合關聯關係創建在抽象層，要求開發者對抽象層進行設計與編程，增長系統的理解和設計難度。

3.2 使用場景

橋接模式的一個經常使用使用場景就是爲了替換繼承，繼承自己具有強侵入性（父類代碼侵入子類），形成子類臃腫，所以，優先使用組合/聚合的方式。

橋接模式的特色是將抽象與實現分離，所以它適合

一個類存在兩個或多個獨立變化的維度，並且這兩個維度都須要擴展
不但願或不適用繼承的場景

3.3 模式對比

橋接模式和抽象工廠模式區別：

這個維度的概念，咱們在抽象工廠中也提到過，這二者都與多個維度相關。可是抽象工廠模式更關注的是對象的建立，是建立型模式，而橋接模式則是更關注的是對象建立以後的動做或功能，因此區別是在這塊。

橋接模式和裝飾者模式區別：

在畫uml 的時候，發現這二者十分的類似，它們都可以避免類爆炸，把繼承變組合，下降了耦合。可是裝飾者模式它是封閉的類，須要用同一個接口裝飾，接口在父類中定義，而橋接模式不用使用同一個接口。

3.4 小結😄

橋接模式一般會於開發前期進行設計，使你可以將程序的各個部分獨立開來以便開發。它的特色將抽象和實現分離，在抽象層創建依賴，從而兩個維度上的實現類能夠進行各自的變化而不會相互影響，具備很是好的擴展性。

設計模式自己在應用中是有必定難度的，須要必定的業務經驗積累，若是哪一天你在哪一個底層源碼中忽然領略到哪一個你看過的模式，就值了，若是哪一天，你在面對業務捉急的時候，忽然把腦門一拍，哎，要不試試裝飾者模式，那你可能就頓悟了，但願那一天離你更近一點。我是瀟雷，若是你以爲本文對你有幫助或啓發，幫忙點個贊，這將是我創做的最好動力！