問題分析：假如我們需要開發乙個同時支援pc和手機的坦克遊戲，遊戲在pc和手機上功能都一樣，都有同樣的型別，面臨同樣的功能需求變化，比如坦克可能有多種不同的型號：t50，t75，t90..對於其中的坦克設計，我們可能很容易設計出來乙個tank的抽象類，然後各種不同型號的tank繼承自該類，但是pc和手機上的圖形繪製、聲效、操作等實現完全不同...因此對於各種型號的坦克，都 要提供各種不同平台上的坦克實現；而這樣的設計帶來了很多問題：有很多重複**，類的結構過於複雜，難以維護，最致命的是引入任何新的平台，比如tv上的tank遊戲，都會讓整個類層次級結構複雜化
動機：思考上述問題的癥結，事實上由於tank型別的固有邏輯，使得tank型別具有了兩個變化的維度——乙個變化的維度為「平台的變化」，乙個變化的維度為「型號的變化」；如何應對這種「多維度的變化」？如何利用物件導向技術使得tank型別可以輕鬆地沿著「平台」和「型號」兩個方向變化，而不引入額外的複雜度
意圖：將抽象部分和實現部分分離（將乙個事物中多個維度的變化分離），使它們可以獨立的變化 即將不同緯度的變化抽象出來，並子類化它們，用物件組合的方式實現應對其變化
可適用性：
設計模式之Bridge
bridge定義 將抽象和行為劃分開來,各自獨立,但能動態的結合.為什麼使用?通常,當乙個抽象類或介面有多個具體實現 concrete subclass 這些concrete之間關係可能有以下兩種 1.這多個具體實現之間恰好是並列的,如前面舉例,打樁,有兩個concrete class 方形樁和圓形...
設計模式之Bridge模式
本文內容是通過學習 設計模式解析 by alan shalloway,james r.trott 一書所總結的心得。博主想通過先提出問題，再解決問題的方式來讓讀者實際體驗一把bridge模式的優勢。這也是 設計模式解析 一書中採用的講解流程，對於讀者理解會有很大幫助 文中的案例也是使用的書中提供的案...
設計模式之bridge 橋 模式
bridge橋接模式是一種結構型模式，它主要應對的是 由於型別的固有羅輯，使得型別具有兩個或兩個以上的緯度變化。也就是要求抽象不應依賴於實現細節，實現細節應依賴於抽象。設計模式 中說到將抽象部分與實現部分分離，使他們可以獨立的變化。舉個例子更清楚些，好像我們平時玩的遊戲中有ps版的，但是不是大家都有...