橋接模式将抽象與具體實作分離，使得抽象與具體實作可以各自改變互不影響。橋接模式屬于設計模式中的結構模式。
橋梁模式涉及的角色
抽象(Abstraction)角色：抽象定義，引用對接口對象的引用。
重新抽象(RefinedAbstraction)角色：重新抽象化角色，對父類中抽象的重新定義。
待實作接口(Implementor)角色：定義待實作的接口。
具體實作(ConcreteImplementor)角色：這個給出實作化角色接口的具體實作。
執行個體
上面的角色描述對應下圖執行個體可以很容易的了解
這樣設計的好處更好的了解面向對象程式設計，而且可以通過組合聚合的形式來完成擴充。
應用場景
會有多種類型的對象存在并且不斷擴充（類似List的及其子類）
解耦兩個子產品或者系統（類似于DriverManager）
總結
這個模式實際開發中不是那麼經常使用，不過對于了解面向對象程式設計是一個很好的模式，可以利用這種模式來完成解耦，并且是整個程式具有良好的擴充性。
橋梁模式是對象的結構模式。又稱為柄體(Handle and Body)模式或接口(Interface)模式。橋梁模式的用意是“将抽象化(Abstraction)與實作化(Implementation)脫耦，使得二者獨立的變化”。
橋梁模式的用意
橋梁模式雖然不是一個使用頻率很高的模式，但是熟悉這個模式對于了解面向對象的設計原則，包括“開－閉”原則以及組合/聚合複用原則都很有幫助，了解好這兩個原則，有助于形成正确的設計思想和培養良好的設計風格。
橋梁模式的用意是“将抽象化(Abstraction)與實作化(Implementation)脫耦，使得二者獨立的變化”。這句話很短，但是第一次讀到這句話的人很可能都會思考良久而不得其解。
這句話有三個關鍵詞，也就是抽象化、實作化和脫耦。了解這三個詞所代表的概念是了解橋梁模式用意的關鍵。
抽象化
從衆多的事物中抽取出共同的、本質性的特征，而舍棄其非本質的特征，就是抽象化。例如：蘋果、香蕉、梨、桃子等。它們共同的特征就是水果。得出水果概念的過程，就是一個抽象化的過程。要抽象，就必須進行比較，沒有比較就無法找到在本質上共同的部分。共同特征是指那些能把一類事物與他類事物分開來的特征，這些具有區分作用的特征�又稱為本質特征。是以抽取事物的共同特征就是抽取事物的本質特征，舍棄非本質的特征。是以抽象化的過程也是一個裁剪的過程。在抽象時，同與不同，決定于從什麼角度上來抽象。抽象的角度決定于分析問題的目的。
通常情況下，一組對象如果具有相同的特征，那麼它們就可以通過一個共同的類來描述。如果一些類具有相同的特征，往往可以通過一個共同的抽象類來描述。
實作化
抽象化給出的具體實作，就是實作化。
一個類的執行個體就是這個類的執行個體化，一個具體子類就是它的抽象超類的執行個體化。
脫耦
所謂耦合，就是兩個實體的行為的某種強關聯。而将它們的強關聯去掉，就是耦合的脫耦。在這裡，脫耦是指将抽象化和執行個體化之間的耦合解脫開，或者是将它們之間的強關聯改成弱關聯。
所謂強關聯，就是在編譯時期已經确定的，無法在運作時期動态改變的關聯；所謂弱關聯，就是可以動态确定并且可以在運作時期動态改變的關聯。顯然，在java語言中，繼承關系是強關聯，而聚合關系是弱關聯。
将兩個角色之間的繼承關系改為聚合關系，就是将它們之間的強關聯改換成為弱關聯，是以，橋梁模式中的所謂脫耦，就是指在一個軟體系統中的抽象化和實作化之間使用聚合關系，而不是繼承關系，進而使兩者可以相對對立的變化。
這就是橋梁模式的用意。
橋梁模式的結構
下圖所示就是一個實作了橋梁模式的示意性系統的結構圖：
橋梁模式結構圖
可以看出，這個系統含有兩個等級結構
- 由抽象化角色和修正抽象化角色組成的抽象化等級結構。
- 由實作化角色和兩個具體實作化角色所組成的實作化等級結構。
橋梁模式涉及的角色有：
- 抽象化角色(Abstraction)：抽象化給出的定義，并儲存一個對實作化對象的引用。
- 修正抽象化角色(RefineAbstraction)：拓展抽象化角色，改變和修正父類對抽象化的定義。
- 實作化角色(Implementor)：這個角色給出實作化角色的接口，但是不給出具體的實作。必須指出的是，這個接口不一定和抽象化角色的定義相同，實際上，這兩個接口可以非常不一樣。實作化角色應當隻給出底層操作，而抽象化角色應當隻給出基于底層操作的更高一層的操作。
- 具體實作化角色(ConcreteImplementor)：這個角色給出實作化角色接口的具體實作。
抽象化角色就像是一個水杯的搖桿，而實作化角色和具體實作化角色就像是水杯的被神。搖桿控制杯身，這就是此模式别名“柄體”的來源。
對象是行為的封裝，而行為是由方法實作的。在這個示意性系統裡，抽象化等級結構中的類封裝了
operation()
方法；而實作化等級結構中的類封裝的是
operationImpl()
方法。當然，在實際的系統中往往會有多于一個的方法。
抽象化等級結構中的方法通過向對應的實作化對象的委派實作自己的功能，這意味着抽象化角色可以通過向不同的實作化對象委派，來達到動态的轉換自己的功能的目的。
示例代碼
實作化角色
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() {
//具體操作
}
}
抽象化角色類，它聲明了一個方法
operation()
，并給出了它的實作。這個實作是通過向實作化對象的委派(也就是調用實作化對象的
operationImpl()
方法)實作的。
public abstract class Abstraction {
protected Implementor implementor;
public Abstraction(Implementor implementor) {
this.implementor = implementor;
}
/**
* 示例方法
*/
public void operation() {
implementor.operationImpl();
}
}
修正抽象化角色
public class RefinedAbstraction extends Abstraction {
public RefinedAbstraction(Implementor implementor) {
super(implementor);
}
/**
* 其他的操作方法
*/
public void otherOperation() {
}
}
一般而言，實作化角色中的每個方法都應當有一個抽象化角色中的某一個方法與之對應，但是反過來則不一定。換而言之，抽象化角色的接口比實作化角色的接口寬。抽象化角色除了提供與實作化角色相關的方法之外，還有可能提供其他的方法；而實作化角色則往往僅為實作抽象化角色的相關行為而存在。
使用場景
考慮這樣一個實際的業務功能：發送提示消息。基本上所有帶業務流程處理的系統都會有這樣的功能，比如OA上有尚未處理完畢的檔案，需要發送一條消息提示他。
從業務上看，消息又分為普通消息、加急消息和特急消息多種，不同的消息類型，業務功能處理是不一樣的，比如加急消息是在消息上添加加急，而特急消息除了添加特急外，還會做一條催促的記錄，多久不完成會繼續催促；從發送消息的手段上看，又有系統内短消息、手機短消息、郵件等。
不使用模式的解決方案
實作發送普通消息
先考慮實作一個簡單點的版本，比如，消息隻是實作發送普通消息，發送的方式隻實作系統内短消息和郵件。其他的功能，等這個版本完成後，再繼續添加。
發送普通消息的結構
消息的統一接口
public interface Message {
/**
* 發送消息
* @param message 發送消息的内容
* @param toUser 接收人
*/
void send (String message, String toUser);
}
系統内短消息示例類
public class CommonMessageSMS implements Message {
@Override
public void send(String message, String toUser) {
System.out.println(String.format("使用系統内部短消息的方法，發送消息 %s 給 %s", message, toUser));
}
}
郵件短消息示例類
public class CommonMessgeEmail implements Message {
@Override
public void send(String message, String toUser) {
System.out.println(String.format("使用郵件短消息的方法，發送消息 %s 給 %s", message, toUser));
}
}
實作發送加急消息
發送加急消息同樣有兩種方式，系統内短消息和郵件方式。但是加急消息的實作不同于普通消息，加急消息會自動在消息上添加加急，然後再發送消息；另外加急消息會提供監控的方法，讓用戶端可以随時通過這個方法來了解對于加急消息的處理進度。比如，相應的人員是否接收到這個消息，相應的處理工作是否已經展開。是以加急消息需要拓展出一個新的接口，除了基本的發送消息的功能，還需要添加監控功能。
實作發送加急消息的結構
加急消息的接口
public interface UrgencyMessage extends Message {
/**
* 監控指定消息的處理過程
* @param messageId 被監控的消息編号
* @return 監控到的消息的處理狀态
*/
Object watch(String messageId);
}
系統内加急短消息示例類
public class UrgencyMessageSMS implements UrgencyMessage {
@Override
public void send(String message, String toUser) {
message = "加急：" + message;
System.out.println(String.format("使用系統内部短消息的方法，發送消息 %s 給 %s", message, toUser));
}
@Override
public Object watch(String messageId) {
//根據消息編碼擷取消息的狀态，組成監控的資料對象，然後傳回
return null;
}
}
郵件加急短消息示例類
public class UrgencyMessageEmail implements UrgencyMessage {
@Override
public void send(String message, String toUser) {
message = "加急：" + message;
System.out.println(String.format("使用郵件短消息的方法，發送消息 %s 給 %s", message, toUser));
}
@Override
public Object watch(String messageId) {
//根據消息編碼擷取消息的狀态，組成監控的資料對象，然後傳回
return null;
}
}
實作發送特急消息
特急消息不需要檢視處理程序，隻有沒有完成，就直接催促，也就是說，對于特急消息，在普通消息的處理基礎上，需要添加催促的功能。
發送特急消息的結構圖
觀察上面的系統結構圖，會發現一個很明顯的問題，那就是通過這種繼承的方式來拓展消息處理，會非常不友善。實作加急消息處理的時候，必須實作系統内短消息和郵件兩種處理方式，因為業務處理可能不同，在實作特急消息處理的時候，又必須實作系統内短消息和郵件兩種處理方式。這意味着，以後每次拓展一次消息處理，都必須要實作這兩種處理方式，這還不算完，如果要添加新的處理方式呢？
添加發送手機消息的處理方式
如果要添加一種新的發送消息的方式，是需要在每一種抽象的具體實作中，都添加發送手機消息的處理的。也就是說，發送普通消息、加急消息、特急消息的處理，都可以通過手機來發送。
添加發送手機消息的處理方式的系統結構圖
采用通過繼承來擴充的實作方式，有個明顯的缺點，擴充消息的種類不太容易。不同種類的消息具有不同的業務，也就是有不同的實作。在這種情況下，每一種類的消息，需要實作所有不同的消息發送方式。更可怕的是，如果要新加入一種消息的發送方式，那麼會要求所有的消息種類都有加入這種新的發送方式的實作。
那麼究竟該如何才能既實作功能，又可以靈活的拓展呢？
使用橋梁模式來解決問題
根據業務的功能要求，業務的變化具有兩個次元，一個次元是抽象的消息，包括普通消息、加急消息和特急消息，這幾個抽象的消息本身就具有一定的關系，加急消息和特急消息會拓展普通消息；另一個次元是在具體的消息發送方式上，包括系統内短消息、郵件短消息和手機短消息，這幾個方式是平等的，可被切換的方式。
;
}
抽象消息類
public abstract class AbstractMessage {
/**
* 持有一個實作部分的對象
*/
MessageImplementor implementor;
/**
* 構造方法，傳入實作部分的對象
* @param implementor 實作部分的對象
*/
public AbstractMessage(MessageImplementor implementor) {
this.implementor = implementor;
}
/**
* 發送消息，委派給實作部分的方法
* @param message 要發送的消息
* @param toUser 接收人
*/
public void sendMessage(String message, String toUser) {
this.implementor.send(message, toUser);
}
}
普通消息類
public class CommonMessage extends AbstractMessage {
/**
* 構造方法，傳入實作部分的對象
*
* @param implementor 實作部分的對象
*/
public CommonMessage(MessageImplementor implementor) {
super(implementor);
}
@Override
public void sendMessage(String message, String toUser) {
//對于普通消息，直接調用父類方法，發送消息即可
super.sendMessage(message, toUser);
}
}
加急消息類
public class UrgencyMessage extends AbstractMessage {
/**
* 構造方法，傳入實作部分的對象
*
* @param implementor 實作部分的對象
*/
public UrgencyMessage(MessageImplementor implementor) {
super(implementor);
}
@Override
public void sendMessage(String message, String toUser) {
message = "加急：" + message;
super.sendMessage(message, toUser);
}
/**
* 擴充它自己的功能，監控某個消息的處理狀态
* @param messageId 消息編碼
* @return 監控到的消息的處理狀态
*/
public Object watch(String messageId) {
//根據給出的消息編碼查詢消息的處理狀态，組織成監控的處理狀态，然後傳回。
return null;
}
}
系統内短消息的實作類
public class MessageSMS implements MessageImplementor {
@Override
public void send(String message, String toUser) {
System.out.println(String.format("使用系統内部短消息的方法，發送消息 %s 給 %s", message, toUser));
}
}
郵件短消息的實作類
public class MessageEmail implements MessageImplementor {
@Override
public void send(String message, String toUser) {
System.out.println(String.format("使用郵件短消息的方法，發送消息 %s 給 %s", message, toUser));
}
}
用戶端類
public class Client {
public static void main (String[] args) {
MessageImplementor implementor = new MessageSMS();
AbstractMessage abstractMessage = new CommonMessage(implementor);
abstractMessage.sendMessage("加班申請速批", "陳總");
implementor = new MessageEmail();
abstractMessage = new UrgencyMessage(implementor);
abstractMessage.sendMessage("加班申請速批", "陳總");
}
}
通過上面的例子會發現，采用橋梁模式來實作，抽象部分和實作部分分離開了，可以互相獨立的變化，而不會互相影響。是以在抽象部分增加新的消息處理(特急消息)，對發送消息的實作部分是沒有影響的；反過來增加發送消息的方式(手機短消息)，對消息處理部分也是沒有影響的。
橋梁模式的優點
-
分離抽象部分和實作部分
橋梁模式分離了抽象部分和實作部分，進而極大的提高了系統的靈活性。讓抽象部分和實作部分獨立出來，分别定義接口，這有助于對系統進行分層，進而産生更好的結構化的系統。
-
更好的擴充性
橋梁模式使得抽象部分和實作部分可以分别獨立的擴充，而不會互相影響，進而大大提高了系統的可擴充性。
橋梁模式在Java中的使用
橋梁模式在Java應用中一個非常典型的例子就是JDBC驅動器。JDBC為所有的關系型資料庫提供一個通用的界面。一個應用系統動态的選擇一個合适的驅動器，然後通過驅動器向資料庫引擎發出指令。這個過程就是将抽象角色的行為委派給實作角色的過程。
抽象角色可以針對任何資料庫引擎發出查詢指令，因為抽象角色并不直接�與資料庫引擎打交道，JDBC驅動器負責這個底層的工作。由于JDBC驅動器的存在，應用系統可以不依賴于資料庫引擎的細節而獨立的演化；同時資料庫引擎也可以獨立�于應用系統的細節而獨立的演化。兩個獨立的等級結構圖如下圖所示，左邊是JDBC API的等級結構，右邊是JDBC驅動器的等級結構，應用程式是建立在JDBC API的基礎之上的。
JDBC等級結構圖
應用系統作為一個等級結構，與JDBC驅動器這個等級結構是相對獨立的，它們之間沒有靜态的強關聯。應用系統通過委派與JDBC驅動器互相作用，這是一個橋梁模式的例子。
JDBC這種架構，把抽象部分和具體實作部分分離開來，進而使得抽象部分和具體實作部分都可以獨立的擴充。對于應用程式而言，之遙選用不同的驅動，就可以讓程式操作不同的資料庫，而無需更改應用程式，進而實作在不同的資料庫上移植；對于驅動程式而言，為資料庫實作不同的驅動程式，并不會影響應用程式。