bridge模式
一 意圖
將抽象部分與它的實現部分分離，使它們都可以獨立的變化。
（類設計的開閉原則：對擴充套件開放，對修改關閉）
二 動機
1 如需增加新的型別window就必須要重新增加新的window類，
且仍然要區分對應平台的window型別，如果要是新增加乙個平台，那整個結構都需要重新新增新的window型別。
2 繼承機制使得客戶**與平台相關。xwindow物件的實現方式僅支援在xwindow平台上執行，包括其所擴充套件的物件，
都只能在xwindow平台上執行，如果要在pmwindow上實現，**不能共享，需要重新移植。
3 依賴性太強，沒有將僅對平台依賴的部分獨立開來，而是不斷的擴充套件不斷的依賴平台。
提供相關的抽象介面和具體平台相關的實現類。
將邏輯介面抽象為window，將具體平台實現抽象為windowimp。
將複雜的類繼承依賴關係結構轉變為組合結構的依賴關係。
三 適用性和結構
1 使抽象和實現部分之間沒有固定的的繫結關係
2 類的抽象和實現都通過它的子類來完成和加以擴充。使得不同的抽象和實現進行任意組合。
3 隱藏實現部分；對抽象部分或者實現部分修改不影響其他部分。
結構
abstraction定義抽象類的介面，維護乙個指向implementor型別的物件指標。
implementor定義實現類的介面，並不一定要與abstraction介面一致，
僅僅是實現類所必需的介面。abstraction提供的是高層次的介面。
將介面和實現分離，解決這種依賴性關係所帶來的系統擴充套件，**復用，系統層次結構問題。
四 **實現
以動機中window為例
1 impementor
2 implementor creator
3 abstrction和refinedabstraction
4 test
5 result
五 例項分析
動態列表資料載入形式：動態列表會包含不確定的大量的資料；
獲取資料的方式形式多樣並不能保持總是同步方式，還需要實時的更新；資料的儲存位置等。
1 簡單基本形式
listmenu提高一系列設定listmenu資料屬性的介面，由客戶端自行去設定而不由系統來維護。
這種實際上就是一種同步的形式，只有資料ready然後將資料傳遞給listmenu。
2 使用bridge模式
這是工作平台上實現方式，是所有使用到列表的地方都要listmenucontentprovider繼承下來類，
既作為客戶端也作為具體對映實現。雖然具有統一性，但是感覺怪怪的。
3 使用bridge模式
將client和concreteimplementor分離開來。
設計模式 Bridge模式
原來對bridge模式理解不是很深入，感覺和build模式很相似，今天又看了四人幫的關於bridge模式的描述，有些新的理解 先來說下適用性 1 不想抽象和實現之間有乙個固定的繫結關係。因為程式在執行時實現部分可以被選擇或者切換 2 類的抽象以及它的實現都應該可以通過生成子類的方法加以擴充。這時br...
設計模式之Bridge模式
本文內容是通過學習 設計模式解析 by alan shalloway,james r.trott 一書所總結的心得。博主想通過先提出問題，再解決問題的方式來讓讀者實際體驗一把bridge模式的優勢。這也是 設計模式解析 一書中採用的講解流程，對於讀者理解會有很大幫助 文中的案例也是使用的書中提供的案...
設計模式學習 Bridge 橋接
意圖 將抽象部分和它的實現部分分離，使得它們都可以獨立的變化 適用性 不希望抽象和實現部分有乙個固定的繫結關係 類的抽象以及它的實現可以通過生成子類的方法加以擴充 對乙個抽象的實現部分的修改應對客戶不產生影響 你對客戶晚產隱藏抽象的實現部分 示例圖 示例 瓶子裝液體，搖晃瓶子，液體跟著蕩漾 填充液體...