定義：Decouple an abstraction from its implementation so that the two can vary independently.（將抽象和實現解耦，使得兩者可以獨立地變化。）
橋樑模式的通用類圖如圖所示。
- Abstraction抽象化角色：它的主要職責是定義出該角色的行爲，同時保存一個對實現化角色的引用，該角色一般是抽象類。
- Implementor實現化角色：它是接口或者抽象類，定義角色必須的行爲和屬性。
- RefinedAbstraction修正抽象化角色：它引用實現化角色對抽象化角色進行修正。
- ConcreteImplementor具體實現化角色：它實現接口和抽象類定義的方法和屬性。
橋樑模式的幾個名詞比較拗口，大家只要記住一句話就成：抽象角色引用實現角色，或者說抽象角色的部分實現是由實現角色完成的。
1.橋樑模式的應用
1.1橋樑模式的優點
- 抽象和實現分離：它完全是爲了解決集成的缺點而提出的設計模式。在該模式下，實現可以不受抽象的約束，不用再綁定在一個固定的抽象層次上。
- 優秀的擴充能力。
- 實現細節對客戶透明。客戶不用關心細節的實現，它已經由抽象層通過聚合關係完成了封裝。
1.2橋樑模式的使用場景
- 不希望或不適合使用集成的場景：例如繼承層次過渡、無法更細化設計顆粒等場景，需要考慮使用橋樑模式。
- 接口或抽象類不穩定的場景：明知道接口不穩定還想通過實現或繼承來實現業務需求，那是得不償失的，也是比較失敗得作法。
- 重用性要求較高的場景：設計的顆粒度越細，則被重用的可能性就越大，而採用繼承則受父類的限制，不可能出現太細的顆粒度。
1.3橋樑模式的注意事項
橋樑模式是非常簡單的，使用該模式時注意考慮如何拆分抽象和實現，並不是一涉及繼承就要考慮使用該模式，那還要繼承幹什麼呢？橋樑模式的意圖還是對變化的封裝，儘量把可能變化的因素封裝到最細、最小的邏輯單元中，避免風險擴散。因此讀者在進行系統設計時，發現類的繼承有N層時，可以考慮使用橋樑模式。