結構型設計模式對比 設計模式（十六）

結構型設計模式

結構型模式關注於總體最終的結構，經過繼承和組合，構建出更加複雜的結構

進而提供更增強大的邏輯功能

七種結構型模式

• 適配器模式（Adapter Pattern）
• 組合模式（Composite Pattern）
• 裝飾器模式（Decorator Pattern）
• 代理模式（Proxy Pattern） 
• 橋接模式（Bridge Pattern）
• 外觀模式（Facade Pattern）
• 享元模式（Flyweight Pattern）

全部的結構型設計模式在邏輯上都各自不一樣程度的隱含了「間接」「代理」「委託」的含義 ，有的明顯，有的含蓄 

 

強表現

適配器、裝飾器、代理、組合、橋接模式，這幾種模式比較強烈的表現了「間接」「代理」「委託」的含義 

從圖中能夠清楚地看得出來，他們都有「代理」的含義

適配器模式，經過繼承或者組合方式，「代理」了，被適配角色Adaptee

裝飾器模式，經過組合的方式，"是你還有你"，內部擁有Component，代理了被裝飾的具體構建 ConcreteComponent

代理模式，經過組合的方式，內部擁有RealSubject，代理了真實主題角色

組合模式，經過組合的方式，內部包含葉子節點或者樹枝節點，內部「代理」了 子對象

橋接模式，經過組合的方式，內部擁有Implementor，指向實現者

 

若是裝飾器模式只有一個被裝飾的類ConcreteComponent，也只有一個裝飾器角色ConcreteDecorator

省略掉Decorator ，他跟代理模式的結構能夠說是同樣的

省略掉裝飾器模式結構圖中的ConcreteDecorator角色，組合模式和裝飾器模式的結構就徹底同樣了

若是隻有一種類型的ConcreteImplementor，橋接模式又與對象適配器模式相同

 

雖說他們都有「代理」的含義，可是他們又有很大差異

適配器模式下，「代理」的對象是功能相近的替代方案，好比，插座適配器能夠進行插頭轉換 使得本來不兼容，不可以一塊兒工做的那些類可以一塊兒工做

代理模式下，「代理」的真實主題的對象RealSubject，從而 對真實對象進行隱藏，封裝 透明的對外界提供服務，控制外界對這個對象的訪問

裝飾器模式下，「代理」的是抽象的Component構建，可以代理全部的ConcreteComponent類型 裝飾器和被裝飾的構建都是Component，重點在於功能的擴展，添加額外的職責

組合模式下，「代理」的是抽象構建Component，代理的是子對象，用於描述「總體-部分」的概念

橋接模式，「代理」的是實現角色Implementor，代理的是具體的實現，用於將抽象與實現進行分離 分離後經過橋接模式進行鏈接

他們雖然都是「代理」，可是他們的側重點不一樣，被代理的事物的性質不一樣

適配器模式在代理的過程當中，重點在於適配，不會增長額外的功能

代理模式側重於控制，固然也一般用於增長功能

若是代理模式，代理的不是真實主題對象RealSubject，而是抽象構建Subject，顯然，就演化成了裝飾器模式

由於代理模式不光可以控制外界對真實對象的訪問，他也可以提供額外的服務

裝飾器模式則是重點在於功能的擴展，增肌額外的職責

而組合模式，重點在於造成「總體--部分」的結構，而且對外界客戶端程序，提供一致的訪問形式

 

弱表現

享元模式和外觀模式也是必定程度的代理

享元模式，經過內部狀態與外部狀態的分離，經過享元池中的享元對象，代理了全部的具備內外狀態完整的對象

對客戶端來講就是有如此多的對象， 只不過內存中卻僅有少許的對象

 

外觀模式在結構上徹底看不出來「代理」的含義，可是他在業務邏輯上充當的也偏偏是「接口人」「協調者」「控制檯」的角色

因此也能夠認爲是「代理」了內部的子系統

 

代理模式與適配器模式

代理模式和適配器模式都須要藉助於內部的「被代理」對象，或者「被適配者」對象進行工做

也就是說他們都將本身的工做委託出去

 

可是代理模式中， 代理者與被代理者他們擁有相同的接口，也就是擁有相同的對外呈現，重點在於對真實對象的隱藏，客戶端請求的透傳，而且能夠額外的增長一些控制，管理

適配器模式中，目標對象和被適配者在接口上沒有必然聯繫，好比目標是港版插座面板，被適配者是大陸插座面板，他們的共同點是提供電力，可是接口卻徹底不一樣

適配器的重點在於不能一塊兒工做的類可以一塊兒工做

 

代理模式與裝飾器模式

代理模式提供與被代理的真實對象相同的訪問接口，對真實對象進行必定的控制，也能夠增長額外的服務，職責

裝飾器模式也是代理了內部真實的對象，而且擁有相同的訪問接口

 

可是代理模式重點在於增長對真實對象的控制，隱藏真實對象，通常會在代理類內部建立一個真實的對象

也就是說這種 代理關係在編譯時期已經靜態肯定了

代理類接受處理來自客戶端的請求，在內部轉發到真實主題對象上

好比

//代理模式
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：上面的分離指分開的，不耦合在一塊兒，不是特指本來是一個總體，被分紅兩部分）

 

以上各個部分的差別對比點主要根據設計模式的最初意圖、動機，設計模式本就是設計原則的實現化角色

對於任何的結構，你均可以按照你本身的想法去使用、拓展，固然，前提是更合適或者更優秀

不然您那是瞎用

好比代理模式與裝飾器模式本就很相似，若是你將代理模式的真實對象也是做爲參數進行傳遞

也是用來動態的增長職責，那麼就成了裝飾器模式，因此再回頭，你說你的是代理模式仍是裝飾器模式？

這麼看這個名字代理仍是裝飾器又有什麼大的區別的呢？都只是用來敘述而已

可是若是你這麼作還非要說是代理模式，有一個很大的問題就是和同事、領導溝通起來就特別費勁了，說不定還會吵起來...

因此，除非你有更好更合適的選擇，或者改變

不然，必定要儘可能按照模式本來的意圖和動機去使用某種模式

 

原文地址: 結構型設計模式對比 設計模式（十六）