設(shè)計模式之7個結(jié)構(gòu)型模式

結(jié)構(gòu)型模式概述

結(jié)構(gòu)型模式(Structural Pattern)描述如何將類或者對象結(jié)合在一起形成更大的結(jié)構(gòu)，就像搭積木，可以通過簡單積木的組合形成復(fù)雜的、功能更為強(qiáng)大的結(jié)構(gòu)。

結(jié)構(gòu)型模式概述
結(jié)構(gòu)型模式可以分為類結(jié)構(gòu)型模式和對象結(jié)構(gòu)型模式

類結(jié)構(gòu)型模式關(guān)心類的組合，由多個類可以組合成一個更大的系統(tǒng)，在類結(jié)構(gòu)型模式中一般只存在繼承關(guān)系和實現(xiàn)關(guān)系。

對象結(jié)構(gòu)型模式關(guān)心類與對象的組合，通過關(guān)聯(lián)關(guān)系使得在一個類中定義另一個類的實例對象，然后通過該對象調(diào)用其方法。根據(jù)“合成復(fù)用原則”，在系統(tǒng)中盡量使用關(guān)聯(lián)關(guān)系來替代繼承關(guān)系，因此大部分結(jié)構(gòu)型模式都是對象結(jié)構(gòu)型模式。
適配器模式(Adapter)
橋接模式(Bridge)
組合模式(Composite)
裝飾模式(Decorator)
外觀模式(Facade)
享元模式(Flyweight)  
代理模式(Proxy)

1適配器模式

把客戶類的請求轉(zhuǎn)化為對適配者的相應(yīng)接口的調(diào)用

1.1 優(yōu)點

將目標(biāo)類和適配者類解耦，通過引入一個適配器類來重用現(xiàn)有的適配者類，而無須修改原有代碼。

增加了類的透明性和復(fù)用性，將具體的實現(xiàn)封裝在適配者類中，對于客戶端類來說是透明的，而且提高了適配者的復(fù)用性。

靈活性和擴(kuò)展性都非常好，通過使用配置文件，可以很方便地更換適配器，也可以在不修改原有代碼的基礎(chǔ)上增加新的適配器類，完全符合“開閉原則”。

1.2 缺點

類適配器模式還具有如下優(yōu)點：

由于適配器類是適配者類的子類，因此可以在適配器類中置換一些適配者的方法，使得適配器的靈活性更強(qiáng)。

類適配器模式的缺點如下：

對于Java、C#等不支持多重繼承的語言，一次最多只能適配一個適配者類，而且目標(biāo)抽象類只能為抽象類，不能為具體類，其使用有一定的局限性，不能將一個適配者類和它的子類都適配到目標(biāo)接口。

對象適配器模式還具有如下優(yōu)點：

一個對象適配器可以把多個不同的適配者適配到同一個目標(biāo)，也就是說，同一個適配器可以把適配者類和它的子類都適配到目標(biāo)接口。

對象適配器模式的缺點如下：

與類適配器模式相比，要想置換適配者類的方法就不容易。如果一定要置換掉適配者類的一個或多個方法，就只好先做一個適配者類的子類，將適配者類的方法置換掉，然后再把適配者類的子類當(dāng)做真正的適配者進(jìn)行適配，實現(xiàn)過程較為復(fù)雜。

1.3情景

系統(tǒng)需要使用現(xiàn)有的類，而這些類的接口不符合系統(tǒng)的需要。

想要建立一個可以重復(fù)使用的類，用于與一些彼此之間沒有太大關(guān)聯(lián)的一些類，包括一些可能在將來引進(jìn)的類一起工作。

1.4類圖

類適配器

對象適配器

Target：目標(biāo)抽象類
Adapter：適配器類
Adaptee：適配者類
Client：客戶類

2.橋接模式

2.1 動機(jī)

橋接模式將繼承關(guān)系轉(zhuǎn)換為關(guān)聯(lián)關(guān)系，從而降低了類與類之間的耦合，減少了代碼編寫量。

2.2 優(yōu)點

分離抽象接口及其實現(xiàn)部分。橋接模式有時類似于多繼承方案，但是多繼承方案違背了類的單一職責(zé)原則（即一個類只有一個變化的原因），復(fù)用性比較差，而且多繼承結(jié)構(gòu)中類的個數(shù)非常龐大，橋接模式是比多繼承方案更好的解決方法。

橋接模式提高了系統(tǒng)的可擴(kuò)充性，在兩個變化維度中任意擴(kuò)展一個維度，都不需要修改原有系統(tǒng)。

實現(xiàn)細(xì)節(jié)對客戶透明，可以對用戶隱藏實現(xiàn)細(xì)節(jié)。

2.3缺點

橋接模式的引入會增加系統(tǒng)的理解與設(shè)計難度，由于聚合關(guān)聯(lián)關(guān)系建立在抽象層，要求開發(fā)者針對抽象進(jìn)行設(shè)計與編程。

橋接模式要求正確識別出系統(tǒng)中兩個獨立變化的維度，因此其使用范圍具有一定的局限性。

2.4 情景

如果一個系統(tǒng)需要在構(gòu)件的抽象化角色和具體化角色之間增加更多的靈活性，避免在兩個層次之間建立靜態(tài)的繼承聯(lián)系，通過橋接模式可以使它們在抽象層建立一個關(guān)聯(lián)關(guān)系。

抽象化角色和實現(xiàn)化角色可以以繼承的方式獨立擴(kuò)展而互不影響，在程序運行時可以動態(tài)將一個抽象化子類的對象和一個實現(xiàn)化子類的對象進(jìn)行組合，即系統(tǒng)需要對抽象化角色和實現(xiàn)化角色進(jìn)行動態(tài)耦合。

一個類存在兩個獨立變化的維度，且這兩個維度都需要進(jìn)行擴(kuò)展。

雖然在系統(tǒng)中使用繼承是沒有問題的，但是由于抽象化角色和具體化角色需要獨立變化，設(shè)計要求需要獨立管理這兩者。

對于那些不希望使用繼承或因為多層次繼承導(dǎo)致系統(tǒng)類的個數(shù)急劇增加的系統(tǒng)，橋接模式尤為適用。

2.5 類圖

Abstraction：抽象類
RefinedAbstraction：擴(kuò)充抽象類
Implementor：實現(xiàn)類接口
ConcreteImplementor：具體實現(xiàn)類

3.組合模式

3.1 動機(jī)

組合模式描述了如何將容器對象和葉子對象進(jìn)行遞歸組合，使得用戶在使用時無須對它們進(jìn)行區(qū)分，可以一致地對待容器對象和葉子對象，這就是組合模式的模式動機(jī)。

3.2 優(yōu)點

可以清楚地定義分層次的復(fù)雜對象，表示對象的全部或部分層次，使得增加新構(gòu)件也更容易。

客戶端調(diào)用簡單，客戶端可以一致的使用組合結(jié)構(gòu)或其中單個對象。

定義了包含葉子對象和容器對象的類層次結(jié)構(gòu)，葉子對象可以被組合成更復(fù)雜的容器對象，而這個容器對象又可以被組合，這樣不斷遞歸下去，可以形成復(fù)雜的樹形結(jié)構(gòu)。

更容易在組合體內(nèi)加入對象構(gòu)件，客戶端不必因為加入了新的對象構(gòu)件而更改原有代碼。

3.3缺點

使設(shè)計變得更加抽象，對象的業(yè)務(wù)規(guī)則如果很復(fù)雜，則實現(xiàn)組合模式具有很大挑戰(zhàn)性，而且不是所有的方法都與葉子對象子類都有關(guān)聯(lián)。

增加新構(gòu)件時可能會產(chǎn)生一些問題，很難對容器中的構(gòu)件類型進(jìn)行限制。

3.4 情景

需要表示一個對象整體或部分層次，在具有整體和部分的層次結(jié)構(gòu)中，希望通過一種方式忽略整體與部分的差異，可以一致地對待它們。

讓客戶能夠忽略不同對象層次的變化，客戶端可以針對抽象構(gòu)件編程，無須關(guān)心對象層次結(jié)構(gòu)的細(xì)節(jié)。

對象的結(jié)構(gòu)是動態(tài)的并且復(fù)雜程度不一樣，但客戶需要一致地處理它們。

3.5 類圖

Component: 抽象構(gòu)件
Leaf: 葉子構(gòu)件
Composite: 容器構(gòu)件
Client: 客戶類
4. 裝飾模式

4.1 動機(jī)

裝飾模式以對客戶透明的方式動態(tài)地給一個對象附加上更多的責(zé)任，換言之，客戶端并不會覺得對象在裝飾前和裝飾后有什么不同。裝飾模式可以在不需要創(chuàng)造更多子類的情況下，將對象的功能加以擴(kuò)展。這就是裝飾模式的模式動機(jī)。

4.2 優(yōu)點

裝飾模式與繼承關(guān)系的目的都是要擴(kuò)展對象的功能，但是裝飾模式可以提供比繼承更多的靈活性。

可以通過一種動態(tài)的方式來擴(kuò)展一個對象的功能，通過配置文件可以在運行時選擇不同的裝飾器，從而實現(xiàn)不同的行為。

通過使用不同的具體裝飾類以及這些裝飾類的排列組合，可以創(chuàng)造出很多不同行為的組合。可以使用多個具體裝飾類來裝飾同一對象，得到功能更為強(qiáng)大的對象。

具體構(gòu)件類與具體裝飾類可以獨立變化，用戶可以根據(jù)需要增加新的具體構(gòu)件類和具體裝飾類，在使用時再對其進(jìn)行組合，原有代碼無須改變，符合“開閉原則”。

4.3缺點

使用裝飾模式進(jìn)行系統(tǒng)設(shè)計時將產(chǎn)生很多小對象，這些對象的區(qū)別在于它們之間相互連接的方式有所不同，而不是它們的類或者屬性值有所不同，同時還將產(chǎn)生很多具體裝飾類。這些裝飾類和小對象的產(chǎn)生將增加系統(tǒng)的復(fù)雜度，加大學(xué)習(xí)與理解的難度。

這種比繼承更加靈活機(jī)動的特性，也同時意味著裝飾模式比繼承更加易于出錯，排錯也很困難，對于多次裝飾的對象，調(diào)試時尋找錯誤可能需要逐級排查，較為煩瑣。

4.4情景

在不影響其他對象的情況下，以動態(tài)、透明的方式給單個對象添加職責(zé)。

需要動態(tài)地給一個對象增加功能，這些功能也可以動態(tài)地被撤銷。 

當(dāng)不能采用繼承的方式對系統(tǒng)進(jìn)行擴(kuò)充或者采用繼承不利于系統(tǒng)擴(kuò)展和維護(hù)時。不能采用繼承的情況主要有兩類：第一類是系統(tǒng)中存在大量獨立的擴(kuò)展，為支持每一種組合將產(chǎn)生大量的子類，使得子類數(shù)目呈爆炸性增長；第二類是因為類定義不能繼承（如final類）。

4.5類圖

Component: 抽象構(gòu)件
ConcreteComponent: 具體構(gòu)件
Decorator: 抽象裝飾類
ConcreteDecorator: 具體裝飾類

5. 外觀模式

5.1 動機(jī)

引入外觀角色之后，用戶只需要直接與外觀角色交互，用戶與子系統(tǒng)之間的復(fù)雜關(guān)系由外觀角色來實現(xiàn)，從而降低了系統(tǒng)的耦合度。

5.2 優(yōu)點

對客戶屏蔽子系統(tǒng)組件，減少了客戶處理的對象數(shù)目并使得子系統(tǒng)使用起來更加容易。通過引入外觀模式，客戶代碼將變得很簡單，與之關(guān)聯(lián)的對象也很少。

實現(xiàn)了子系統(tǒng)與客戶之間的松耦合關(guān)系，這使得子系統(tǒng)的組件變化不會影響到調(diào)用它的客戶類，只需要調(diào)整外觀類即可。

降低了大型軟件系統(tǒng)中的編譯依賴性，并簡化了系統(tǒng)在不同平臺之間的移植過程，因為編譯一個子系統(tǒng)一般不需要編譯所有其他的子系統(tǒng)。一個子系統(tǒng)的修改對其他子系統(tǒng)沒有任何影響，而且子系統(tǒng)內(nèi)部變化也不會影響到外觀對象。

只是提供了一個訪問子系統(tǒng)的統(tǒng)一入口，并不影響用戶直接使用子系統(tǒng)類。

5.3缺點

不能很好地限制客戶使用子系統(tǒng)類，如果對客戶訪問子系統(tǒng)類做太多的限制則減少了可變性和靈活性。

在不引入抽象外觀類的情況下，增加新的子系統(tǒng)可能需要修改外觀類或客戶端的源代碼，違背了“開閉原則”。

5.4情景

當(dāng)要為一個復(fù)雜子系統(tǒng)提供一個簡單接口時可以使用外觀模式。該接口可以滿足大多數(shù)用戶的需求，而且用戶也可以越過外觀類直接訪問子系統(tǒng)。

客戶程序與多個子系統(tǒng)之間存在很大的依賴性。引入外觀類將子系統(tǒng)與客戶以及其他子系統(tǒng)解耦，可以提高子系統(tǒng)的獨立性和可移植性。

在層次化結(jié)構(gòu)中，可以使用外觀模式定義系統(tǒng)中每一層的入口，層與層之間不直接產(chǎn)生聯(lián)系，而通過外觀類建立聯(lián)系，降低層之間的耦合度。

5.5類圖

Facade: 外觀角色
SubSystem:子系統(tǒng)角色

6. 享元模式

6.1 動機(jī)

在享元模式中共享的是享元對象的內(nèi)部狀態(tài)，外部狀態(tài)需要通過環(huán)境來設(shè)置。在實際使用中，能夠共享的內(nèi)部狀態(tài)是有限的，因此享元對象一般都設(shè)計為較小的對象，它所包含的內(nèi)部狀態(tài)較少，這種對象也稱為細(xì)粒度對象。享元模式的目的就是使用共享技術(shù)來實現(xiàn)大量細(xì)粒度對象的復(fù)用。

6.2 優(yōu)點

享元模式的優(yōu)點在于它可以極大減少內(nèi)存中對象的數(shù)量，使得相同對象或相似對象在內(nèi)存中只保存一份。

享元模式的外部狀態(tài)相對獨立，而且不會影響其內(nèi)部狀態(tài)，從而使得享元對象可以在不同的環(huán)境中被共享。

6.3缺點

享元模式使得系統(tǒng)更加復(fù)雜，需要分離出內(nèi)部狀態(tài)和外部狀態(tài)，這使得程序的邏輯復(fù)雜化。

為了使對象可以共享，享元模式需要將享元對象的狀態(tài)外部化，而讀取外部狀態(tài)使得運行時間變長。

6.4情景

一個系統(tǒng)有大量相同或者相似的對象，由于這類對象的大量使用，造成內(nèi)存的大量耗費。

對象的大部分狀態(tài)都可以外部化，可以將這些外部狀態(tài)傳入對象中。

使用享元模式需要維護(hù)一個存儲享元對象的享元池，而這需要耗費資源，因此，應(yīng)當(dāng)在多次重復(fù)使用享元對象時才值得使用享元模式。

6.5類圖

Flyweight: 抽象享元類
ConcreteFlyweight: 具體享元類
UnsharedConcreteFlyweight: 非共享具體享元類
FlyweightFactory: 享元工廠類

7.代理模式

7.1 動機(jī)

通過引入一個新的對象（如小圖片和遠(yuǎn)程代理對象）來實現(xiàn)對真實對象的操作或者將新的對象作為真實對象的一個替身，這種實現(xiàn)機(jī)制即為代理模式，通過引入代理對象來間接訪問一個對象，這就是代理模式的模式動機(jī)。

7.2 優(yōu)點

代理模式能夠協(xié)調(diào)調(diào)用者和被調(diào)用者，在一定程度上降低了系統(tǒng)的耦合度。

遠(yuǎn)程代理使得客戶端可以訪問在遠(yuǎn)程機(jī)器上的對象，遠(yuǎn)程機(jī)器可能具有更好的計算性能與處理速度，可以快速響應(yīng)并處理客戶端請求。

虛擬代理通過使用一個小對象來代表一個大對象，可以減少系統(tǒng)資源的消耗，對系統(tǒng)進(jìn)行優(yōu)化并提高運行速度。

保護(hù)代理可以控制對真實對象的使用權(quán)限。

7.3缺點

由于在客戶端和真實主題之間增加了代理對象，因此有些類型的代理模式可能會造成請求的處理速度變慢。

實現(xiàn)代理模式需要額外的工作，有些代理模式的實現(xiàn)非常復(fù)雜。

7.4情景

根據(jù)代理模式的使用目的，常見的代理模式有以下幾種類型：

遠(yuǎn)程(Remote)代理：為一個位于不同的地址空間的對象提供一個本地的代理對象，這個不同的地址空間可以是在同一臺主機(jī)中，也可是在另一臺主機(jī)中，遠(yuǎn)程代理又叫做大使(Ambassador)。

虛擬(Virtual)代理：如果需要創(chuàng)建一個資源消耗較大的對象，先創(chuàng)建一個消耗相對較小的對象來表示，真實對象只在需要時才會被真正創(chuàng)建。

Copy-on-Write代理：它是虛擬代理的一種，把復(fù)制（克隆）操作延遲到只有在客戶端真正需要時才執(zhí)行。一般來說，對象的深克隆是一個開銷較大的操作，Copy-on-Write代理可以讓這個操作延遲，只有對象被用到的時候才被克隆。

根據(jù)代理模式的使用目的，代理模式有以下幾種類型（續(xù)）：

保護(hù)(Protect or Access)代理：控制對一個對象的訪問，可以給不同的用戶提供不同級別的使用權(quán)限。

緩沖(Cache)代理：為某一個目標(biāo)操作的結(jié)果提供臨時的存儲空間，以便多個客戶端可以共享這些結(jié)果。

防火墻(Firewall)代理：保護(hù)目標(biāo)不讓惡意用戶接近。

同步化(Synchronization)代理：使幾個用戶能夠同時使用一個對象而沒有沖突。

智能引用(Smart Reference)代理：當(dāng)一個對象被引用時，提供一些額外的操作，如將此對象被調(diào)用的次數(shù)記錄下來等。

7.5類圖

Subject: 抽象主題角色
Proxy: 代理主題角色
RealSubject: 真實主題角色