本文內容是通過學習《設計模式解析》 by - alan shalloway, james r. trott 一書所總結的心得。
博主想通過先提出問題，再解決問題的方式來讓讀者實際體驗一把bridge模式的優勢。（這也是《設計模式解析》一書中採用的講解流程，對於讀者理解會有很大幫助）文中的案例也是使用的書中提供的案例。
先看需求：有兩個繪製例項d1和d2，它們都提供了drawline和drawcircle方法，但是方法的內部實現邏輯是不一樣的。需要分別使用它們來繪製rectangle和circle兩種形狀。請問要如何實現？
各位看官不如自己思考一下自己將如何實現這個需求。。。
首先，我們建立乙個shape類，建立d1shape和d2shape並且它們都繼承於shape，它們分別對應於d1和d2兩個繪製例項。
其次，為了解耦我們讓rectangle和circle類負責自己的繪製，比如rectangle的繪製就在draw()方法中完成，實現過程就是呼叫d1的drawline方法四次即可。
最後，因為有兩種繪製例項d1和d2，那麼就需要分別與之對應的d1rectangle，d2rectangle，d1circle，d2circle，它們四個分別繼承於d1shape和d2shape類。
那麼類圖如下所示：
ok，需求已經實現了。
但是問題也很明顯，如果此時要增加一種形狀oval，那麼就需要新增兩個類d1oval,d2oval，這是一種**式增長。而若是增加一種繪製例項d3，那簡直變成乙個鬼畜般的需求了。。。
所以，上面的這種設計方式肯定是不行的，那麼到底要怎樣來設計呢？
既然要寫的是bridge模式，那麼肯定是用橋接模式來解決這個問題。
首先，我們來抽象一下這個具體的問題，以便我們在其他地方遇到類似問題也能想到bridge模式
這裡包含乙個抽象概念shape和乙個實現概念繪製例項d1,d2,而在我們上面的方案中shape和d1，d2是緊耦合的，所以當需求變更時，需要大量的修改。
而bridge模式的目的就是：將抽象與實現進行解耦。這裡的「實現」是上文提到的「實現概念」，而不是說某個介面的實現類。這裡比較不好理解。
那麼，bridge模式如何實現解耦呢？
首先，我們還是建立shape類，但是不建立d1shape和d2shape。
其次，我們將d1和d2抽象出乙個drawing介面，然後讓drawing1和drawing2分別實現這個介面，並且使drawing1對應d1,drawing2對應d2（這裡可通過adapter模式將d1,d2包裝進去）
接著，我們在shape中新增乙個drawing物件，在繪製的時候通過drawing物件來執行繪製。
請看類圖：
我們只要在建立shape時通過建構函式將drawing物件傳遞進來就可以了。
public
void
shape(drawing drawing)
說了這麼多，那這麼設計到底有什麼優點呢？
1.請您自己去檢查下需求是否實現了。。。
2.如果需要新增乙個d3，我們只需要新建乙個drawing3即可
3.如果要增加一種shape，如果這種shape也是通過drawline和drawcircle方法來繪製，那從shape類派生乙個子類即可。
4.如果3中的條件不滿足，就會稍微麻煩一點。比如增加橢圓oval，需要乙個drawoval方法來繪製。這時就需要修改drawing介面。但是這種麻煩也在可接受範圍內吧！
設計模式之Bridge
bridge定義 將抽象和行為劃分開來,各自獨立,但能動態的結合.為什麼使用?通常,當乙個抽象類或介面有多個具體實現 concrete subclass 這些concrete之間關係可能有以下兩種 1.這多個具體實現之間恰好是並列的,如前面舉例,打樁,有兩個concrete class 方形樁和圓形...
設計模式之bridge 橋 模式
bridge橋接模式是一種結構型模式，它主要應對的是 由於型別的固有羅輯，使得型別具有兩個或兩個以上的緯度變化。也就是要求抽象不應依賴於實現細節，實現細節應依賴於抽象。設計模式 中說到將抽象部分與實現部分分離，使他們可以獨立的變化。舉個例子更清楚些，好像我們平時玩的遊戲中有ps版的，但是不是大家都有...
設計模式 Bridge模式
原來對bridge模式理解不是很深入，感覺和build模式很相似，今天又看了四人幫的關於bridge模式的描述，有些新的理解 先來說下適用性 1 不想抽象和實現之間有乙個固定的繫結關係。因為程式在執行時實現部分可以被選擇或者切換 2 類的抽象以及它的實現都應該可以通過生成子類的方法加以擴充。這時br...