一、基本概念
橋梁模式（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與模式》之橋梁模式）
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/8569.html
標籤：設計模式