《JAVA與模式》之橋樑模式

標籤：nrv   sem   atp   stl   arp   相互   noi   let   郵件   

橋樑模式是對象的結構模式。又稱為柄體(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的這種架構，把抽象部分和具體部分分離開來，從而使得抽象部分和具體部分都可以獨立地擴充。對於應用程式而言，只要選用不同的驅動，就可以讓程式操作不同的資料庫，而無需更改應用程式，從而實現在不同的資料庫上移植；對於驅動程式而言，為資料庫實現不同的驅動程式，並不會影響應用程式。

《JAVA與模式》之橋樑模式