天天學習一個設計模式（二）：結構型之橋樑模式

1、基本概念

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

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

• 抽象化

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

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

• 實現化

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

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

• 脫耦

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

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

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

 

2、通俗解釋

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

 

3、使用場景

考慮這樣一個實際的業務功能：發送提示消息。基本上全部帶業務流程處理的系統都會有這樣的功能，好比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("加班申請速批","李總");
    }
}

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

4、橋樑模式的優勢

　●　分離抽象和實現部分

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

　●　更好的擴展性

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

5、橋樑模式在Java中的使用

橋樑模式在Java應用中的一個很是典型的例子就是JDBC驅動器。JDBC爲全部的關係型數據庫提供一個通用的界面。一個應用系統動態地選擇一個合適的驅動器，而後經過驅動器向數據庫引擎發出指令。這個過程就是將抽象角色的行爲委派給實現角色的過程。

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

                                 

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

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

---

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