一、基本概念

橋梁模式（Bridge）是對象的結構模式。又稱為柄體(Handle and Body)模式或介面(Interface)模式。橋梁模式的用意是“將抽象化(Abstraction)與實現化(Implementation)脫耦，使得二者可以獨立地變化”。

這句話有三個關鍵詞，也就是抽象化、實現化和脫耦。理解這三個詞所代表的概念是理解橋梁模式用意的關鍵。

• 抽象化

　　從眾多的事物中抽取出共同的、本質性的特征，而捨棄其非本質的特征，就是抽象化。例如蘋果、香蕉、生梨、 桃子等，它們共同的特性就是水果。得出水果概念的過程，就是一個抽象化的過程。要抽象，就必須進行比較，沒有比較就無法找到在本質上共同的部分。共同特征是指那些能把一類事物與他類事物區分開來的特征，這些具有區分作用的特征又稱本質特征。因此抽取事物的共同特征就是抽取事物的本質特征，捨棄非本質的特征。 所以抽象化的過程也是一個裁剪的過程。在抽象時，同與不同，決定於從什麼角度上來抽象。抽象的角度取決於分析問題的目的。

　　通常情況下，一組對象如果具有相同的特征，那麼它們就可以通過一個共同的類來描述。如果一些類具有相同的特征，往往可以通過一個共同的抽象類來描述。

• 實現化

　　抽象化給出的具體實現，就是實現化。

　　一個類的實例就是這個類的實例化，一個具體子類是它的抽象超類的實例化。

• 脫耦

　　所謂耦合，就是兩個實體的行為的某種強關聯。而將它們的強關聯去掉，就是耦合的解脫，或稱脫耦。在這裡，脫耦是指將抽象化和實現化之間的耦合解脫開，或者說是將它們之間的強關聯改換成弱關聯。

　　所謂強關聯，就是在編譯時期已經確定的，無法在運行時期動態改變的關聯；所謂弱關聯，就是可以動態地確定並且可以在運行時期動態地改變的關聯。顯然，在Java語言中，繼承關係是強關聯，而聚合關係是弱關聯。

　　將兩個角色之間的繼承關係改為聚合關係，就是將它們之間的強關聯改換成為弱關聯。因此，橋梁模式中的所謂脫耦，就是指在一個軟體系統的抽象化和實現化之間使用聚合關係而不是繼承關係，從而使兩者可以相對獨立地變化。這就是橋梁模式的用意。

二、通俗解釋

BRIDGE 橋梁模式：早上碰到MM，要說早上好，晚上碰到MM，要說晚上好；碰到MM穿了件新衣服，要說你的衣服好漂亮哦，碰到MM新做的髮型，要說你的頭髮好漂亮哦。不要問我“早上碰到MM新做了個髮型怎麼說”這種問題，自己用BRIDGE組合一下不就行了 橋梁模式：將抽象化與實現化脫耦，使得二者可以獨立的變化，也就是說將他們之間的強關聯變成弱關聯，也就是指在一個軟體系統的抽象化和實現化之間使用組合/聚合關係而不是繼承關係，從而使兩者可以獨立的變化。

三、使用場景

考慮這樣一個實際的業務功能：發送提示消息。基本上所有帶業務流程處理的系統都會有這樣的功能，比如OA上有尚未處理完畢的文件，需要發送一條消息提示他。

從業務上看，消息又分成普通消息、加急消息和特急消息多種，不同的消息類型，業務功能處理是不一樣的，比如加急消息是在消息上添加加急，而特急消息除了添加特急外，還會做一條催促的記錄，多久不完成會繼續催促；從發送消息的手段上看，又有系統內短消息、手機簡訊息、郵件等。

不使用模式的解決方案

實現發送普通消息

　　先考慮實現一個簡單點的版本，比如，消息只是實現發送普通消息，發送的方式只實現系統內短消息和郵件。其他的功能，等這個版本完成後，再繼續添加。

消息的統一介面

public interface Message {
    /**
     * 發送消息
     * @param message 要發送消息的內容
     * @param toUser  消息的接受者
     */
    public void send(String message , String toUser);
}

系統內短消息示例類

public class CommonMessageSMS implements Message {

    @Override
    public void send(String message, String toUser) {

        System.out.println("使用系統內短消息的方法，發送消息'"+message+"'給"+toUser);
    }
}

郵件消息示例類

public class CommonMessageEmail implements Message{

    @Override
    public void send(String message, String toUser) {

        System.out.println("使用郵件短消息的方法，發送消息'"+message+"'給"+toUser);
    }
}

實現發送加急消息

發送加急消息同樣有兩種方式，系統內短消息和郵件方式。但是加急消息的實現不同於普通消息，加急消息會自動在消息上添加加急，然後在再發送消息；另外加急消息會提供監控的方法，讓客戶端可以隨時通過這個方法來瞭解對於加急消息的處理進度。比如，相應的人員是否接收到這個信息，相應的處理工作是否已經展開。因此加急消息需要擴展出一個新的介面，除了基本的發送消息的功能，還需要添加監控功能。

加急消息的介面

public interface UrgencyMessage extends Message {
    /**
     * 監控指定消息的處理過程
     * @param messageId  被監控的消息編號
     * @return    監控到的消息的處理狀態
     */
    public Object watch(String messageId);
}

系統內加急短消息示例類

public class UrgencyMessageSMS implements UrgencyMessage {

    @Override
    public Object watch(String messageId) {
        // 根據消息id獲取消息的狀態，組織成監控的數據對象，然後返回
        return null;
    }

    @Override
    public void send(String message, String toUser) {
        
        message = "加急：" + message;
        System.out.println("使用系統內短消息的方法，發送消息'"+message+"'給"+toUser);
    }
}

郵件加急短消息示例類

public class UrgencyMessageEmail implements UrgencyMessage {

    @Override
    public Object watch(String messageId) {
        // 根據消息id獲取消息的狀態，組織成監控的數據對象，然後返回
        return null;
    }

    @Override
    public void send(String message, String toUser) {
        
        message = "加急：" + message;
        System.out.println("使用郵件短消息的方法，發送消息'"+message+"'給"+toUser);
    }
}

實現發送特急消息

特急消息不需要查看處理進程，只有沒有完成，就直接催促，也就是說，對於特急消息，在普通消息的處理基礎上，需要添加催促的功能。

觀察上面的系統結構圖，會發現一個很明顯的問題，那就是通過這種繼承的方式來擴展消息處理，會非常不方便。實現加急消息處理的時候，必須實現系統內短消息和郵件兩種處理方式，因為業務處理可能不同，在實現特急消息處理的時候，又必須實現系統內簡訊息和郵件兩種處理方式。這意味著，以後每次擴展一下消息處理，都必須要實現這兩種處理方式，這還不算完，如果要添加新的實現方式呢？

添加發送手機消息的處理方式

如果要添加一種新的發送消息的方式，是需要在每一種抽象的具體實現中，都添加發送手機消息的處理的。也就是說，發送普通消息、加急消息和特急消息的處理，都可以通過手機來發送。

採用通過繼承來擴展的實現方式，有個明顯的缺點，擴展消息的種類不太容易。不同種類的消息具有不同的業務，也就是有不同的實現，在這種情況下，每一種類的消息，需要實現所有不同的消息發送方式。更可怕的是，如果要新加入一種消息的發送方式，那麼會要求所有的消息種類都有加入這種新的發送方式的實現。

那麼究竟該如何才能既實現功能，又可以靈活地擴展呢？

使用橋梁模式來解決問題

根據業務的功能要求，業務的變化具有兩個維度，一個維度是抽象的消息，包括普通消息、加急消息和特急消息，這幾個抽象的消息本身就具有一定的關係，加急消息和特急消息會擴展普通消息；另一個維度是在具體的消息發送方式上，包括系統內短消息、郵件和手機短消息，這幾個方式是平等的，可被切換的方式。

現在出現問題的根本原因，就在於消息的抽象和實現是混雜在一起的，這就導致了一個緯度的變化會引起另一個緯度進行相應的變化，從而使得程式擴展起來非常困難。

要想解決這個問題，就必須把這兩個緯度分開，也就是將抽象部分和實現部分分開，讓它們相互獨立，這樣就可以實現獨立的變化，使擴展變得簡單。抽象部分就是各個消息的類型所對應的功能，而實現部分就是各種發送消息的方式。按照橋梁模式的結構，給抽象部分和實現部分分別定義介面，然後分別實現它們就可以了。

抽象消息類

public abstract class AbstractMessage {
    //持有一個實現部分的對象
    MessageImplementor impl;
    /**
     * 構造方法，傳入實現部分的對象
     * @param impl  實現部分的對象
     */
    public AbstractMessage(MessageImplementor impl){
        this.impl = impl;
    }
    /**
     * 發送消息，委派給實現部分的方法
     * @param message    要發送消息的內容
     * @param toUser    消息的接受者
     */
    public void sendMessage(String message , String toUser){
        this.impl.send(message, toUser);
    }
}

普通消息類

public class CommonMessage extends AbstractMessage {

    public CommonMessage(MessageImplementor impl) {
        super(impl);
    }
    @Override
    public void sendMessage(String message, String toUser) {
        // 對於普通消息，直接調用父類方法，發送消息即可
        super.sendMessage(message, toUser);
    }
}

加急消息類

public class UrgencyMessage extends AbstractMessage {

    public UrgencyMessage(MessageImplementor impl) {
        super(impl);
    }
    @Override
    public void sendMessage(String message, String toUser) {
        message = "加急：" + message;
        super.sendMessage(message, toUser);
    }
    /**
     * 擴展自己的新功能，監控某消息的處理狀態
     * @param messageId    被監控的消息編號
     * @return    監控到的消息的處理狀態
     */
    public Object watch(String messageId) {
        // 根據消息id獲取消息的狀態，組織成監控的數據對象，然後返回
        return null;
    }
}

實現發送消息的統一介面

public interface MessageImplementor {
    /**
     * 發送消息
     * @param message 要發送消息的內容
     * @param toUser  消息的接受者
     */
    public void send(String message , String toUser);
}

系統內短消息的實現類

public class MessageSMS implements MessageImplementor {

    @Override
    public void send(String message, String toUser) {
        
        System.out.println("使用系統內短消息的方法，發送消息'"+message+"'給"+toUser);
    }
}

郵件短消息的實現類

public class MessageEmail implements MessageImplementor {

    @Override
    public void send(String message, String toUser) {
        System.out.println("使用郵件短消息的方法，發送消息'"+message+"'給"+toUser);
    }
}

客戶端類

public class Client {

    public static void main(String[] args) {
        //創建具體的實現對象
        MessageImplementor impl = new MessageSMS();
        //創建普通消息對象
        AbstractMessage message = new  CommonMessage(impl);
        message.sendMessage("加班申請速批","李總");
        
        //將實現方式切換成郵件，再次發送
        impl = new MessageEmail();
        //創建加急消息對象
        message = new UrgencyMessage(impl);
        message.sendMessage("加班申請速批","李總");
    }
}

觀察上面的例子會發現，採用橋梁模式來實現，抽象部分和實現部分分離開了，可以相互獨立的變化，而不會相互影響。因此在抽象部分添加新的消息處理（特急消息），對發送消息的實現部分是沒有影響的；反過來增加發送消息的方式（手機短消息），對消息處理部分也是沒有影響的。

四、橋梁模式的優點

　●　分離抽象和實現部分

　　橋梁模式分離了抽象部分和實現部分，從而極大地提供了系統的靈活性。讓抽象部分和實現部分獨立出來，分別定義介面，這有助於對系統進行分層，從而產生更好的結構化的系統。

　●　更好的擴展性

　　橋梁模式使得抽象部分和實現部分可以分別獨立地擴展，而不會相互影響，從而大大提高了系統的可擴展性。

五、橋梁模式在Java中的使用

橋梁模式在Java應用中的一個非常典型的例子就是JDBC驅動器。JDBC為所有的關係型資料庫提供一個通用的界面。一個應用系統動態地選擇一個合適的驅動器，然後通過驅動器向資料庫引擎發出指令。這個過程就是將抽象角色的行為委派給實現角色的過程。

抽象角色可以針對任何資料庫引擎發出查詢指令，因為抽象角色並不直接與資料庫引擎打交道，JDBC驅動器負責這個底層的工作。由於JDBC驅動器的存在，應用系統可以不依賴於資料庫引擎的細節而獨立地演化；同時資料庫引擎也可以獨立於應用系統的細節而獨立的演化。兩個獨立的等級結構如下圖所示，左邊是JDBC API的等級結構，右邊是JDBC驅動器的等級結構。應用程式是建立在JDBC API的基礎之上的。

應用系統作為一個等級結構，與JDBC驅動器這個等級結構是相對獨立的，它們之間沒有靜態的強關聯。應用系統通過委派與JDBC驅動器相互作用，這是一個橋梁模式的例子。

JDBC的這種架構，把抽象部分和具體部分分離開來，從而使得抽象部分和具體部分都可以獨立地擴展。對於應用程式而言，只要選用不同的驅動，就可以讓程式操作不同的資料庫，而無需更改應用程式，從而實現在不同的資料庫上移植；對於驅動程式而言，為資料庫實現不同的驅動程式，並不會影響應用程式。

（引用：《JAVA與模式》之橋梁模式）