結構型設計模式藉助於組合或者繼承以整體結構的形式提供更強大的功能，他們之間有很多點非常相似，本文對七個結構型設計模式進行了對比，代理模式，裝飾器模式，享元模式，橋接模式，外觀模式，組合模式，適配器模式他們之間的異同點，差異點進行了分析，有助於更好地理解學習各種模式。 ...
結構型設計模式 結構型模式關註於整體最終的結構，通過繼承和組合，構建出更加複雜的結構 進而提供更加強大的邏輯功能 七種結構型模式
- 適配器模式（Adapter Pattern）
- 組合模式（Composite Pattern）
- 裝飾器模式（Decorator Pattern）
- 代理模式（Proxy Pattern）
- 橋接模式（Bridge Pattern）
- 外觀模式（Facade Pattern）
- 享元模式（Flyweight Pattern）
強表現
適配器、裝飾器、代理、組合、橋接模式，這幾種模式比較強烈的表現了“間接”“代理”“委托”的含義
從圖中可以清楚地看得出來，他們都有“代理”的含義
| 適配器模式，通過繼承或者組合方式，“代理”了，被適配角色Adaptee |
| 裝飾器模式，通過組合的方式，"是你還有你"，內部擁有Component，代理了被裝飾的具體構建 ConcreteComponent |
| 代理模式，通過組合的方式，內部擁有RealSubject，代理了真實主題角色 |
| 組合模式，通過組合的方式，內部包含葉子節點或者樹枝節點，內部“代理”了 子對象 |
| 橋接模式，通過組合的方式，內部擁有Implementor，指向實現者 |
| 適配器模式下，“代理”的對象是功能相近的替代方案，比如，插座適配器可以進行插頭轉換 使得原本不相容，不能夠一起工作的那些類能夠一起工作 |
| 代理模式下，“代理”的真實主題的對象RealSubject，從而對真實對象進行隱藏，封裝 透明的對外界提供服務，控制外界對這個對象的訪問 |
| 裝飾器模式下，“代理”的是抽象的Component構建，能夠代理所有的ConcreteComponent類型 裝飾器和被裝飾的構建都是Component，重點在於功能的擴展，添加額外的職責 |
| 組合模式下，“代理”的是抽象構建Component，代理的是子對象，用於描述“整體-部分”的概念 |
| 橋接模式，“代理”的是實現角色Implementor，代理的是具體的實現，用於將抽象與實現進行分離 分離後通過橋接模式進行連接 |
//代理模式 public class Proxy implements Subject{ private Subject realSubject; public Proxy(){ //關係在編譯時確定 realSubject = new RealSubject(); } public void doSth(){ …. realSubject.doSth(); …. } }裝飾器模式在於功能的動態增加，所以對象一般作為參數進行傳遞，比如: InputStream inputStream = new BufferedInputStream(new FileInputStream("........")); 這是一種在運行期間動態增加功能方式 適配器與外觀模式 適配器模式將一種介面轉換為另外一種介面，使得原本不能一起工作的類可以協作 外觀模式是將子系統的的多個介面的訪問轉換為另一種介面，使得原本複雜難用，耦合程度高的多個類有一個一致簡單的介面 他們都變成了另外一種形式的介面 所有的請求也都是委托他人進行處理，適配器模式委托給被適配角色，外觀模式委托給子系統 適配器模式是為了能夠一起工作，他們原本是並不相容的 外觀模式是為了能夠更好地更簡單的工作，他們原本是可以一起工作的 橋接模式與適配器模式 適配器模式的主要目的是讓因為介面不相容而不能互相工作的類能夠一起工作 換句話說就是他們本身不同，我用“紐帶” Adapter將他們連接起來
而橋接模式則是將原本或許緊密結合在一起的抽象與實現，進行分離 使她們能夠各自獨立的發展，是把連接在一起的兩個事物，拆分開來 然後用“紐帶”“橋梁”（也就是對象的引用）將他們連接起來
適配器模式就好比張三和王五不認識，李四介紹他們認識 橋梁模式好比張三和王五成天黏在一起活幹得不好太亂套，李四說以後我作為介面人，你倆各乾各的吧 雖然看起來都是兩個人幹活，中間一個聯繫人，但是含義卻是完全不同
橋接模式與裝飾器模式 裝飾器模式中，使用組合而不是繼承來對類的功能進行擴展 避免了類的個數的爆炸增長，與橋梁模式的結果不約而同 他們都解決了類爆炸增長的問題，都避免了過多的沒必要的子類
裝飾器模式側重於功能的動態增加，將額外的功能提取到子類中 通過不同的排列組合，形成一個遞歸的調用方式，以動態的增加各部分的功能
橋梁模式是將原本系統中的實現細節抽取出來，比如原來抽象概念與實例化全部都是一個類層次結構中 把所有的實現細節，比如示例中的平臺相關實現，抽取出來，進行分離，達到抽象與實現分離的目的
所以雖然他們都可以解決子類爆炸式增長、不易擴展的問題 但是他們的出發點完全不同 一個關註於功能的動態擴展組合 一個關註於抽象與實現的分離，獲得更多的靈活性 總結 所有的結構型模式的都離不開“分離，解耦”的概念 而“分離，解耦”之後，又通過某種形式建立聯繫，比如“組合” 抽象與實現進行分離，分離就意味著獨立，獨立就意味著可以單獨發展，橋接模式 對於分離的事物通過委托的形式托付工作，就可以在中間提供更多的服務，代理模式 而分離的兩個事物也可以通過一定形式的結合、轉換進而一起協同工作，適配器模式 將一個對象的多個功能點進行分離，從而能夠動態的組合以形成更強大的功能，裝飾器模式 將事物自身內部核心狀態與外部狀態進行分離，進而減少核心狀態的存儲運行消耗，享元模式 將客戶端與子系統的耦合交互進行分離，抽象出來一個新的接入點，外觀Facade，降低耦合，外觀模式 分離開的多種事物，如果他們有“整體--部分”的關係，可以將它們組合在一起，形成更複雜的整體結構，組合模式 （ps：上面的分離指分開的，不耦合在一起，不是特指原本是一個整體，被分成兩部分） 以上各個部分的差異對比點主要根據設計模式的最初意圖、動機，設計模式本就是設計原則的實現化角色 對於任何的結構，你都可以按照你自己的想法去使用、拓展，當然，前提是更合適或者更優秀 否則您那是瞎用 比如代理模式與裝飾器模式本就很類似，如果你將代理模式的真實對象也是作為參數進行傳遞 也是用來動態的增加職責，那麼就成了裝飾器模式，所以再回頭，你說你的是代理模式還是裝飾器模式？ 這麼看這個名字代理還是裝飾器又有什麼大的區別的呢？都只是用來敘述而已 但是如果你這麼做還非要說是代理模式，有一個很大的問題就是和同事、領導溝通起來就特別費勁了，說不定還會吵起來... 所以，除非你有更好更合適的選擇，或者改變 否則，一定要儘量按照模式原本的意圖和動機去使用某種模式 原文地址:結構型設計模式對比 設計模式（十六）
