橋樑模式（Bridge Pattern）

一、 橋樑（Bridge）模式 

橋樑模式是一個非常有用的模式，也是比較複雜的一個模式。熟悉這個模式對於理解物件導向的設計原則，包括"開－閉"原則(OCP)以及組合/彙總複用原則(CARP)都很有協助。理解好這兩個原則，有助於形成正確的設計思想和培養良好的設計風格。註：《Java 與模式》一書認為 Bridge模式不是一個使用頻率很高的模式，我不太贊同，我認為 Bridge模式中蘊涵了很多設計模式的關鍵思想在裡面，所以我這裡採納了《Design Patterns Explained》一書的作者 Alan Shalloway與 James R. Trott的觀點：The Bridge pattern is quite a bit more complex than the other patterns you just learned; it is also much more useful.

 橋樑模式的用意 【GOF95】在提出橋樑模式的時候指出，橋樑模式的用意是"將抽象化(Abstraction)與實現化(Implementation)脫耦，使得二者可以獨立地變化"。這句話有三個關鍵詞，也就是抽象化、實現化和脫耦。

 抽象化 

存在於多個實體中的共同的概念性聯絡，就是抽象化。作為一個過程，抽象化就是忽略一些資訊，從而把不同的實體當做同樣的實體對待【LISKOV94】。

 實現化

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

脫耦 

所謂耦合，就是兩個實體的行為的某種強關聯。而將它們的強關聯去掉，就是耦合的解脫，或稱脫耦。在這裡，脫耦是指將抽象化和實現化之間的耦合解脫開，或者說是將它們之間的強關聯改換成弱關聯。將兩個角色之間的繼承關係改為彙總關係，就是將它們之間的強關聯改換成為弱關聯。因此，橋樑模式中的所謂脫耦，就是指在一個軟體系統的抽象化和實現化之間使用組合/彙總關係而不是繼承關係，從而使兩者可以相對獨立地變化。這就是橋樑模式的用意。

二、 橋樑模式的結構 

橋樑模式【GOF95】是對象的結構模式，又稱為柄體(Handle and Body)模式或介面(Interface)模式。 所示就是一個實現了橋樑模式的示意性系統的結構圖。 

可以看出，這個系統含有兩個等級結構，也就是：

 1.  由抽象化角色和修正抽象化角色群組成的抽象化等級結構。

 2.  由實現化角色和兩個具體實現化角色所組成的實現化等級結構。 橋樑模式所涉及的角色有： 

抽象化(Abstraction)角色：抽象化給出的定義，並儲存一個對實現化對象的引用。 

修正抽象化(Refined Abstraction)角色：擴充抽象化角色，改變和修正父類對抽象化的定義。  

實現化(Implementor)角色：這個角色給出實現化角色的介面，但不給出具體的實現。必須指出的是，這個介面不一定和抽象化角色的介面定義相同，實際上，這兩個介面可以非常不一樣。實現化角色應當只給出底層操作，而抽象化角色應當只給出基於底層操作的更高一層的操作。 

具體實現化(Concrete Implementor)角色：這個角色給出實現化角色介面的具體實現。 

三、 數據機問題 

感覺《敏捷式軟體開發 (Agile Software Development)－原則、模式與實踐》中關於 Bridge 模式的例子很好。（《Java 與模式》一書 33 章的對變化的封裝一節也寫得很不錯，推薦大家讀一讀。它深入的闡述了《Design Patterns Explained》一書中"1）Design to interfaces. 2)Favor composition over inheritance. 3)Find what varies and encapsulate it"的三個觀點。）。

，有大量的數據機客戶程式在使用 Modem介面。Modem介面被幾個衍生類別 HayesModem、USRoboticsModem和 EarniesModem實現。它很好地遵循了 OCP、LSP 和DIP。當增加新種類的數據機時，數據機的客戶程式不會受影響。 假定這種情形持續了幾年，並有許多數據機的客戶程式都在使用著 Modem 介面。現出現了一種不撥號的數據機，被稱為專用數據機。它們位於一條專用連線的兩端。有幾個新應用程式使用這些專用數據機，它們無需撥號。我們稱這些使用者為 DedUser。但是，客戶希望當前所有的數據機客戶程式都可以使用這些專用數據機。他們不希望去更改許許多多的數據機客戶應用程式，所以完全可以讓這些數據機客戶程式去撥一些假(dummy)電話號碼。如果能選擇的話，我們會把系統的設計更改為所示的那樣。 我們把撥號和通訊功能分離為兩個不同的介面。原來的數據機實現這兩個介面，而數據機客戶程式使用這兩個介面。DedUser只使用 Modem介面，而 DedicateModem 只實現Modem 介面。但這樣做會要求我們更改所有的數據機客戶程式--這是客戶不允許的。 一個可能的解決方案是讓 DedicatedModem 從 Modem派生並且把 dial 方法和 hangup 方法實現為空白，就像這樣： 幾個月後，已經有了大量的DedUser，此時客戶提出了一個新的更改。為了能撥國際電話號碼、信用卡電話等，必修對現有 dial 中使用char[10]儲存號碼改為能夠撥打任意長度的電話號碼。顯然，所有的數據機客戶程式都必須更改。客戶同意了對數據機客戶程式的更改，因為他們別無選擇。糟糕的是，現在必須要去告訴 DedUser 的編寫者，他們必須要更改他們的代碼！你可以想象他們聽到這個會有多高興。本來他們是不用調用 dial 的。這就是許多項目都會具有的那種有害的混亂依賴關係。系統某一部分中的一個雜湊體(kludge)建立了一個有害的依賴關係，最終導致系統中完全無關的部分出現問題。如果使用ADAPTER模式解決最初的問題的話，就可以避免這個嚴重問題。 請注意，雜湊體仍然存在。適配器仍然要類比串連狀態。然而，所有的依賴關係都是從適配器發起的。雜湊體和系統隔離，藏身於幾乎無人知曉的適配器中。 BRIDGE模式 看待這個問題，還有另外一個方式。現在，出現了另外一種切分 Modem 階層的方式。如： 這不是一個理想的結構。每當增加一款新硬體時，就必須建立兩個新類--一個針對專用的情況，一個針對撥號的情況。每當增加一種新連線類型時，就必須建立3 個新類，分別對應 3款不同的硬體。如果這兩個自由度根本就是不穩定的，那麼不用多久，就會出現大量的衍生類別。在類型階層具有多個自由度的情況中，BRIDGE模式通常是有用的。我們可以把這些階層分開並通過橋把它們結合到一起，而不是把它們合并起來。我們把數據機類階層分成兩個階層。一個表示串連方法，另一個表示硬體。 這個結構雖然複雜，但是很有趣。它的建立不會影響到數據機的使用者，並且還完全分離了串連策略和硬體實現。ModemConnectController的每個衍生類別代表了一個新的串連策略。在這個策略的實現中可以使用sendlmp、 receivelmp、diallmp和 hanglmp。新 imp方法的增加不會影響到使用者。可以使用 ISP 來給串連控制類增加新的介面。這種做法可以建立出一條遷移路徑，數據機的客戶程式可以沿著這條路徑慢慢地得到一個比 dial和hangup層次更高的 API。四、 在什麼情況下應當使用橋樑模式 根據上面的分析，在以下的情況下應當使用橋樑模式：   

• 如果一個系統需要在構件的抽象化角色和具體化角色之間增加更多的靈活性，避免在兩個層次之間建立靜態聯絡。
•   設計要求實現化角色的任何改變不應當影響用戶端，或者說實現化角色的改變對用戶端是完全透明的。
•     一個構件有多於一個的抽象化角色和實現化角色，系統需要它們之間進行動態耦合。
•     雖然在系統中使用繼承是沒有問題的，但是由於抽象化角色和具體化角色需要獨立變化，設計要求需要獨立管理這兩者。 

James W. Cooper，《C#設計模式》