橋樑（Bridge）模式

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

橋樑模式的用意

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

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

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

• 　　抽象化

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

　　一般狀況下，一組對象若是具備相同的特徵，那麼它們就能夠經過一個共同的類來描述。若是一些類具備相同的特徵，每每能夠經過一個共同的抽象類來描述。

• 　　實現化

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

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

• 　　脫耦

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

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

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

橋樑模式的結構

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

　　能夠看出，這個系統含有兩個等級結構：

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

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

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

　　●　　抽象化(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的這種架構，把抽象部分和具體部分分離開來，從而使得抽象部分和具體部分均可以獨立地擴展。對於應用程序而言，只要選用不一樣的驅動，就 可讓程序操做不一樣的數據庫，而無需更改應用程序，從而實如今不一樣的數據庫上移植；對於驅動程序而言，爲數據庫實現不一樣的驅動程序，並不會影響應用程序。