橋樑模式是對象的結構模式。又稱為柄體(Handle and Body)模式或接口(Interface)模式。橋樑模式的用意是「將抽象化(Abstraction)與實現化(Implementation)脫耦，使得二者可以獨立地變化」。

橋樑模式的用意

　　橋樑模式雖然不是一個使用頻率很高的模式，但是熟悉這個模式對於理解面向對象的設計原則，包括「開-閉」原則以及組合/聚合復用原則都很有幫助。理解好這兩個原則，有助於形成正確的設計思想和培養良好的設計風格。

　　橋樑模式的用意是「將抽象化(Abstraction)與實現化(Implementation)脫耦，使得二者可以獨立地變化」。這句話很短，但是第一次讀到這句話的人很可能都會思考良久而不解其意。

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

• 　　抽象化

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

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

• 　　實現化

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

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

• 　　脫耦

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

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

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

橋樑模式的結構

　　下圖所示就是一個實現了橋樑模式的示意性系統的結構圖：

　　可以看出，這個系統含有兩個等級結構：

　　一、由抽象化角色和修正抽象化角色組成的抽象化等級結構。

　　二、由實現化角色和兩個具體實現化角色所組成的實現化等級結構。

　　橋樑模式所涉及的角色有：

　　●　　抽象化(Abstraction)角色：抽象化給出的定義，並保存一個對實現化對象的引用。

　　●　　修正抽象化(RefinedAbstraction)角色：擴展抽象化角色，改變和修正父類對抽象化的定義。

　　●　　實現化(Implementor)角色：這個角色給出實現化角色的接口，但不給出具體的實現。必須指出的是，這個接口不一定和抽象化角色的接口定義相同，實際上，這兩個接口可以非常不一樣。實現化角色應當只給出底層操作，而抽象化角色應當只給出基於底層操作的更高一層的操作。

　　●　　具體實現化(ConcreteImplementor)角色：這個角色給出實現化角色接口的具體實現。

　　抽象化角色就像是一個水杯的手柄，而實現化角色和具體實現化角色就像是水杯的杯身。手柄控制杯身，這就是此模式別名「柄體」的來源。

　　對象是對行為的封裝，而行為是由方法實現的。在這個示意性系統里，抽象化等級結構中的類封裝了operation()方法；而實現化等級結構中的類封裝的是operationImpl()方法。當然，在實際的系統中往往會有多於一個的方法。

　　抽象化等級結構中的方法通過向對應的實現化對象的委派實現自己的功能，這意味著抽象化角色可以通過向不同的實現化對象委派，來達到動態地轉換自己的功能的目的。

原始碼

　　抽象化角色類，它聲明了一個方法operation()，並給出了它的實現。這個實現是通過向實現化對象的委派(調用operationImpl()方法)實現的。

public abstract class Abstraction {
    
    protected Implementor impl;
    
    public Abstraction(Implementor impl){
        this.impl = impl;
    }
    //示例方法
    public void operation(){
        
        impl.operationImpl();
    }
}

　　修正抽象化角色

public class RefinedAbstraction extends Abstraction {
    
    public RefinedAbstraction(Implementor impl) {
        super(impl);
    }
    //其他的操作方法
    public void otherOperation(){
        
    }
}

　　實現化角色

public abstract class Implementor {
    /**
     * 示例方法，實現抽象部分需要的某些具體功能
     */
    public abstract void operationImpl();
}

　　具體實現化角色

public class ConcreteImplementorA extends Implementor {

    @Override
    public void operationImpl() {
        //具體操作
    }

}

public class ConcreteImplementorB extends Implementor {

    @Override
    public void operationImpl() {
        //具體操作
    }

}

　　一般而言，實現化角色中的每個方法都應當有一個抽象化角色中的某一個方法與之對應，但是反過來則不一定。換言之，抽象化角色的接口比實現化角色的接口寬。抽象化角色除了提供與實現化角色相關的方法之外，還有可能提供其他的方法；而實現化角色則往往僅為實現抽象化角色的相關行為而存在。

使用場景

　　考慮這樣一個實際的業務功能：發送提示消息。基本上所有帶業務流程處理的系統都會有這樣的功能，比如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的這種架構，把抽象部分和具體部分分離開來，從而使得抽象部分和具體部分都可以獨立地擴展。對於應用程式而言，只要選用不同的驅動，就可以讓程序操作不同的資料庫，而無需更改應用程式，從而實現在不同的資料庫上移植；對於驅動程序而言，為資料庫實現不同的驅動程序，並不會影響應用程式。