第9章 結構型設計模式

第9章結構型設計模式《軟件體系結構與設計實用教程》第二版結構型模式結構型模式概述結構型模式(StructuralPattern)描述如何將類或者對象結合在一起形成更大的結構。結構型模式結構型模式概述結構型模式可以分為類結構型模式和對象結構型模式：類結構型模式關心類的組合，由多個類可以組合成一個更大的系統(tǒng)，在類結構型模式中一般只存在繼承關系和實現(xiàn)關系。對象結構型模式關心類與對象的組合，通過關聯(lián)關系使得在一個類中定義另一個類的實例對象，然后通過該對象調(diào)用其方法。根據(jù)“合成復用原則”，在系統(tǒng)中盡量使用關聯(lián)關系來替代繼承關系，因此大部分結構型模式都是對象結構型模式。結構型模式結構型模式簡介適配器模式(Adapter)橋接模式(Bridge)組合模式(Composite)裝飾模式(Decorator)外觀模式(Facade)享元模式(Flyweight)代理模式(Proxy)9.1外觀模式模式動機引入外觀角色之后，用戶只需要直接與外觀角色交互，用戶與子系統(tǒng)之間的復雜關系由外觀角色來實現(xiàn)，從而降低了系統(tǒng)的耦合度。外觀模式模式定義外觀模式(FacadePattern)：外部與一個子系統(tǒng)的通信必須通過一個統(tǒng)一的外觀對象進行，為子系統(tǒng)中的一組接口提供一個一致的界面，外觀模式定義了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用。外觀模式又稱為門面模式，它是一種對象結構型模式。外觀模式模式結構外觀模式模式結構外觀模式包含如下角色：Facade:外觀角色SubSystem:子系統(tǒng)角色外觀模式模式分析根據(jù)“單一職責原則”，在軟件中將一個系統(tǒng)劃分為若干個子系統(tǒng)有利于降低整個系統(tǒng)的復雜性，一個常見的設計目標是使子系統(tǒng)間的通信和相互依賴關系達到最小，而達到該目標的途徑之一就是引入一個外觀對象，它為子系統(tǒng)的訪問提供了一個簡單而單一的入口。外觀模式也是“迪米特法則”的體現(xiàn)，通過引入一個新的外觀類可以降低原有系統(tǒng)的復雜度，同時降低客戶類與子系統(tǒng)類的耦合度。外觀模式模式分析外觀模式要求一個子系統(tǒng)的外部與其內(nèi)部的通信通過一個統(tǒng)一的外觀對象進行，外觀類將客戶端與子系統(tǒng)的內(nèi)部復雜性分隔開，使得客戶端只需要與外觀對象打交道，而不需要與子系統(tǒng)內(nèi)部的很多對象打交道。外觀模式的目的在于降低系統(tǒng)的復雜程度。外觀模式從很大程度上提高了客戶端使用的便捷性，使得客戶端無須關心子系統(tǒng)的工作細節(jié)，通過外觀角色即可調(diào)用相關功能。外觀模式模式分析典型的外觀角色代碼：publicclassFacade{privateSubSystemAobj1=newSubSystemA();privateSubSystemBobj2=newSubSystemB();privateSubSystemCobj3=newSubSystemC();publicvoidmethod(){obj1.method();obj2.method();obj3.method();}}

外觀模式模式優(yōu)缺點外觀模式的優(yōu)點對客戶屏蔽子系統(tǒng)組件，減少了客戶處理的對象數(shù)目并使得子系統(tǒng)使用起來更加容易。通過引入外觀模式，客戶代碼將變得很簡單，與之關聯(lián)的對象也很少。實現(xiàn)了子系統(tǒng)與客戶之間的松耦合關系，這使得子系統(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)類。外觀模式模式優(yōu)缺點外觀模式的缺點不能很好地限制客戶使用子系統(tǒng)類，如果對客戶訪問子系統(tǒng)類做太多的限制則減少了可變性和靈活性。在不引入抽象外觀類的情況下，增加新的子系統(tǒng)可能需要修改外觀類或客戶端的源代碼，違背了“開閉原則”。外觀模式模式適用環(huán)境在以下情況下可以使用外觀模式：當要為一個復雜子系統(tǒng)提供一個簡單接口時可以使用外觀模式。該接口可以滿足大多數(shù)用戶的需求，而且用戶也可以越過外觀類直接訪問子系統(tǒng)。客戶程序與多個子系統(tǒng)之間存在很大的依賴性。引入外觀類將子系統(tǒng)與客戶以及其他子系統(tǒng)解耦，可以提高子系統(tǒng)的獨立性和可移植性。在層次化結構中，可以使用外觀模式定義系統(tǒng)中每一層的入口，層與層之間不直接產(chǎn)生聯(lián)系，而通過外觀類建立聯(lián)系，降低層之間的耦合度。9.2適配器模式模式動機在軟件開發(fā)中采用類似于電源適配器的設計和編碼技巧被稱為適配器模式。通常情況下，客戶端可以通過目標類的接口訪問它所提供的服務。有時，現(xiàn)有的類可以滿足客戶類的功能需要，但是它所提供的接口不一定是客戶類所期望的，這可能是因為現(xiàn)有類中方法名與目標類中定義的方法名不一致等原因所導致的。在這種情況下，現(xiàn)有的接口需要轉化為客戶類期望的接口，這樣保證了對現(xiàn)有類的重用。如果不進行這樣的轉化，客戶類就不能利用現(xiàn)有類所提供的功能，適配器模式可以完成這樣的轉化。適配器模式模式動機在適配器模式中可以定義一個包裝類，包裝不兼容接口的對象，這個包裝類指的就是適配器(Adapter)，它所包裝的對象就是適配者(Adaptee)，即被適配的類。適配器提供客戶類需要的接口，適配器的實現(xiàn)就是把客戶類的請求轉化為對適配者的相應接口的調(diào)用。也就是說：當客戶類調(diào)用適配器的方法時，在適配器類的內(nèi)部將調(diào)用適配者類的方法，而這個過程對客戶類是透明的，客戶類并不直接訪問適配者類。因此，適配器可以使由于接口不兼容而不能交互的類可以一起工作。這就是適配器模式的模式動機。適配器模式模式定義適配器模式(AdapterPattern)：將一個接口轉換成客戶希望的另一個接口，適配器模式使接口不兼容的那些類可以一起工作，其別名為包裝器(Wrapper)。適配器模式既可以作為類結構型模式，也可以作為對象結構型模式。適配器模式模式結構類適配器適配器模式模式結構對象適配器適配器模式模式結構適配器模式包含如下角色：Target：目標抽象類Adapter：適配器類Adaptee：適配者類Client：客戶類適配器模式模式分析典型的類適配器代碼：publicclassAdapter

extendsAdapteeimplementsTarget{ publicvoidrequest() {

specificRequest(); }}適配器模式模式分析典型的對象適配器代碼：publicclassAdapterextendsTarget{ privateAdapteeadaptee;

publicAdapter(Adapteeadaptee) { this.adaptee=adaptee; }

publicvoidrequest() {

adaptee.specificRequest(); }}適配器模式模式優(yōu)缺點適配器模式的優(yōu)點將目標類和適配者類解耦，通過引入一個適配器類來重用現(xiàn)有的適配者類，而無須修改原有代碼。增加了類的透明性和復用性，將具體的實現(xiàn)封裝在適配者類中，對于客戶端類來說是透明的，而且提高了適配者的復用性。靈活性和擴展性都非常好，通過使用配置文件，可以很方便地更換適配器，也可以在不修改原有代碼的基礎上增加新的適配器類，完全符合“開閉原則”。適配器模式模式優(yōu)缺點類適配器模式還具有如下優(yōu)點：由于適配器類是適配者類的子類，因此可以在適配器類中置換一些適配者的方法，使得適配器的靈活性更強。類適配器模式的缺點如下：對于Java、C#等不支持多重繼承的語言，一次最多只能適配一個適配者類，而且目標抽象類只能為抽象類，不能為具體類，其使用有一定的局限性，不能將一個適配者類和它的子類都適配到目標接口。適配器模式模式優(yōu)缺點對象適配器模式還具有如下優(yōu)點：一個對象適配器可以把多個不同的適配者適配到同一個目標，也就是說，同一個適配器可以把適配者類和它的子類都適配到目標接口。對象適配器模式的缺點如下：與類適配器模式相比，要想置換適配者類的方法就不容易。如果一定要置換掉適配者類的一個或多個方法，就只好先做一個適配者類的子類，將適配者類的方法置換掉，然后再把適配者類的子類當做真正的適配者進行適配，實現(xiàn)過程較為復雜。適配器模式模式適用環(huán)境在以下情況下可以使用適配器模式：系統(tǒng)需要使用現(xiàn)有的類，而這些類的接口不符合系統(tǒng)的需要。想要建立一個可以重復使用的類，用于與一些彼此之間沒有太大關聯(lián)的一些類，包括一些可能在將來引進的類一起工作。9.3橋接模式模式動機對于有兩個變化維度（即兩個變化的原因）的系統(tǒng)，采用方案二來進行設計系統(tǒng)中類的個數(shù)更少，且系統(tǒng)擴展更為方便。設計方案二即是橋接模式的應用。橋接模式將繼承關系轉換為關聯(lián)關系，從而降低了類與類之間的耦合，減少了代碼編寫量。橋接模式模式定義橋接模式(BridgePattern)：將抽象部分與它的實現(xiàn)部分分離，使它們都可以獨立地變化。它是一種對象結構型模式，又稱為柄體(HandleandBody)模式或接口(Interface)模式。橋接模式模式結構橋接模式模式結構橋接模式包含如下角色：Abstraction：抽象類RefinedAbstraction：擴充抽象類Implementor：實現(xiàn)類接口ConcreteImplementor：具體實現(xiàn)類

橋接模式模式分析理解橋接模式，重點需要理解如何將抽象化(Abstraction)與實現(xiàn)化(Implementation)脫耦，使得二者可以獨立地變化。抽象化：抽象化就是忽略一些信息，把不同的實體當作同樣的實體對待。在面向對象中，將對象的共同性質抽取出來形成類的過程即為抽象化的過程。實現(xiàn)化：針對抽象化給出的具體實現(xiàn)，就是實現(xiàn)化，抽象化與實現(xiàn)化是一對互逆的概念，實現(xiàn)化產(chǎn)生的對象比抽象化更具體，是對抽象化事物的進一步具體化的產(chǎn)物。脫耦：脫耦就是將抽象化和實現(xiàn)化之間的耦合解脫開，或者說是將它們之間的強關聯(lián)改換成弱關聯(lián)，將兩個角色之間的繼承關系改為關聯(lián)關系。橋接模式中的所謂脫耦，就是指在一個軟件系統(tǒng)的抽象化和實現(xiàn)化之間使用關聯(lián)關系（組合或者聚合關系）而不是繼承關系，從而使兩者可以相對獨立地變化，這就是橋接模式的用意。橋接模式模式分析典型的實現(xiàn)類接口代碼：publicinterfaceImplementor{ publicvoidoperationImpl();}橋接模式模式分析典型的抽象類代碼：publicabstractclassAbstraction{ protectedImplementorimpl;

publicvoidsetImpl(Implementorimpl) { this.impl=impl; }

publicabstractvoidoperation();}橋接模式模式分析典型的擴充抽象類代碼：publicclassRefinedAbstractionextendsAbstraction{ publicvoidoperation() { //代碼

impl.operationImpl(); //代碼

}}

橋接模式模式優(yōu)缺點橋接模式的優(yōu)點分離抽象接口及其實現(xiàn)部分。橋接模式有時類似于多繼承方案，但是多繼承方案違背了類的單一職責原則（即一個類只有一個變化的原因），復用性比較差，而且多繼承結構中類的個數(shù)非常龐大，橋接模式是比多繼承方案更好的解決方法。橋接模式提高了系統(tǒng)的可擴充性，在兩個變化維度中任意擴展一個維度，都不需要修改原有系統(tǒng)。實現(xiàn)細節(jié)對客戶透明，可以對用戶隱藏實現(xiàn)細節(jié)。橋接模式模式優(yōu)缺點橋接模式的缺點橋接模式的引入會增加系統(tǒng)的理解與設計難度，由于聚合關聯(lián)關系建立在抽象層，要求開發(fā)者針對抽象進行設計與編程。橋接模式要求正確識別出系統(tǒng)中兩個獨立變化的維度，因此其使用范圍具有一定的局限性。橋接模式模式適用環(huán)境在以下情況下可以使用橋接模式：如果一個系統(tǒng)需要在構件的抽象化角色和具體化角色之間增加更多的靈活性，避免在兩個層次之間建立靜態(tài)的繼承聯(lián)系，通過橋接模式可以使它們在抽象層建立一個關聯(lián)關系。抽象化角色和實現(xiàn)化角色可以以繼承的方式獨立擴展而互不影響，在程序運行時可以動態(tài)將一個抽象化子類的對象和一個實現(xiàn)化子類的對象進行組合，即系統(tǒng)需要對抽象化角色和實現(xiàn)化角色進行動態(tài)耦合。一個類存在兩個獨立變化的維度，且這兩個維度都需要進行擴展。雖然在系統(tǒng)中使用繼承是沒有問題的，但是由于抽象化角色和具體化角色需要獨立變化，設計要求需要獨立管理這兩者。對于那些不希望使用繼承或因為多層次繼承導致系統(tǒng)類的個數(shù)急劇增加的系統(tǒng)，橋接模式尤為適用。9.4組合模式模式動機對于樹形結構，當容器對象（如文件夾）的某一個方法被調(diào)用時，將遍歷整個樹形結構，尋找也包含這個方法的成員對象（可以是容器對象，也可以是葉子對象，如子文件夾和文件）并調(diào)用執(zhí)行。（遞歸調(diào)用）由于容器對象和葉子對象在功能上的區(qū)別，在使用這些對象的客戶端代碼中必須有區(qū)別地對待容器對象和葉子對象，而實際上大多數(shù)情況下客戶端希望一致地處理它們，因為對于這些對象的區(qū)別對待將會使得程序非常復雜。組合模式模式動機組合模式描述了如何將容器對象和葉子對象進行遞歸組合，使得用戶在使用時無須對它們進行區(qū)分，可以一致地對待容器對象和葉子對象，這就是組合模式的模式動機。組合模式模式定義組合模式(CompositePattern)：組合多個對象形成樹形結構以表示“整體-部分”的結構層次。組合模式對單個對象（即葉子對象）和組合對象（即容器對象）的使用具有一致性。組合模式又可以稱為“整體-部分”(Part-Whole)模式，屬于對象的結構模式，它將對象組織到樹結構中，可以用來描述整體與部分的關系。組合模式模式結構組合模式模式結構組合模式包含如下角色：Component:抽象構件Leaf:葉子構件Composite:容器構件Client:客戶類組合模式模式分析組合模式的關鍵是定義了一個抽象構件類，它既可以代表葉子，又可以代表容器，而客戶端針對該抽象構件類進行編程，無須知道它到底表示的是葉子還是容器，可以對其進行統(tǒng)一處理。同時容器對象與抽象構件類之間還建立一個聚合關聯(lián)關系，在容器對象中既可以包含葉子，也可以包含容器，以此實現(xiàn)遞歸組合，形成一個樹形結構。組合模式模式分析典型的抽象構件角色代碼：publicabstractclassComponent{ publicabstractvoidadd(Componentc); publicabstractvoidremove(Componentc); publicabstractComponentgetChild(inti); publicabstractvoidoperation();}組合模式模式分析典型的葉子構件角色代碼：publicclassLeafextendsComponent{ publicvoidadd(Componentc) {//異常處理或錯誤提示}

publicvoidremove(Componentc) {//異常處理或錯誤提示}

publicComponentgetChild(inti) {//異常處理或錯誤提示}

publicvoidoperation() { //實現(xiàn)代碼

}}

組合模式模式分析典型的容器構件角色代碼：publicclassCompositeextendsComponent{ privateArrayListlist=newArrayList();

publicvoidadd(Componentc) { list.add(c); }

publicvoidremove(Componentc) { list.remove(c); }

publicComponentgetChild(inti) { (Component)list.get(i); }

publicvoidoperation() { for(Objectobj:list) { ((Component)obj).operation(); } } }

組合模式模式優(yōu)缺點組合模式的優(yōu)點可以清楚地定義分層次的復雜對象，表示對象的全部或部分層次，使得增加新構件也更容易。客戶端調(diào)用簡單，客戶端可以一致的使用組合結構或其中單個對象。定義了包含葉子對象和容器對象的類層次結構，葉子對象可以被組合成更復雜的容器對象，而這個容器對象又可以被組合，這樣不斷遞歸下去，可以形成復雜的樹形結構。更容易在組合體內(nèi)加入對象構件，客戶端不必因為加入了新的對象構件而更改原有代碼。組合模式模式優(yōu)缺點組合模式的缺點使設計變得更加抽象，對象的業(yè)務規(guī)則如果很復雜，則實現(xiàn)組合模式具有很大挑戰(zhàn)性，而且不是所有的方法都與葉子對象子類都有關聯(lián)。增加新構件時可能會產(chǎn)生一些問題，很難對容器中的構件類型進行限制。組合模式模式適用環(huán)境在以下情況下可以使用組合模式：需要表示一個對象整體或部分層次，在具有整體和部分的層次結構中，希望通過一種方式忽略整體與部分的差異，可以一致地對待它們。讓客戶能夠忽略不同對象層次的變化，客戶端可以針對抽象構件編程，無須關心對象層次結構的細節(jié)。對象的結構是動態(tài)的并且復雜程度不一樣，但客戶需要一致地處理它們。9.5裝飾模式模式動機一般有兩種方式可以實現(xiàn)給一個類或對象增加行為：繼承機制，使用繼承機制是給現(xiàn)有類添加功能的一種有效途徑，通過繼承一個現(xiàn)有類可以使得子類在擁有自身方法的同時還擁有父類的方法。但是這種方法是靜態(tài)的，用戶不能控制增加行為的方式和時機。關聯(lián)機制，即將一個類的對象嵌入另一個對象中，由另一個對象來決定是否調(diào)用嵌入對象的行為以便擴展自己的行為，我們稱這個嵌入的對象為裝飾器(Decorator)。裝飾模式模式動機裝飾模式以對客戶透明的方式動態(tài)地給一個對象附加上更多的責任，換言之，客戶端并不會覺得對象在裝飾前和裝飾后有什么不同。裝飾模式可以在不需要創(chuàng)造更多子類的情況下，將對象的功能加以擴展。這就是裝飾模式的模式動機。裝飾模式模式定義裝飾模式(DecoratorPattern)：動態(tài)地給一個對象增加一些額外的職責(Responsibility)，就增加對象功能來說，裝飾模式比生成子類實現(xiàn)更為靈活。其別名也可以稱為包裝器(Wrapper)，與適配器模式的別名相同，但它們適用于不同的場合。根據(jù)翻譯的不同，裝飾模式也有人稱之為“油漆工模式”，它是一種對象結構型模式。裝飾模式模式結構裝飾模式模式結構裝飾模式包含如下角色：Component:抽象構件ConcreteComponent:具體構件Decorator:抽象裝飾類ConcreteDecorator:具體裝飾類裝飾模式模式分析與繼承關系相比，關聯(lián)關系的主要優(yōu)勢在于不會破壞類的封裝性，而且繼承是一種耦合度較大的靜態(tài)關系，無法在程序運行時動態(tài)擴展。在軟件開發(fā)階段，關聯(lián)關系雖然不會比繼承關系減少編碼量，但是到了軟件維護階段，由于關聯(lián)關系使系統(tǒng)具有較好的松耦合性，因此使得系統(tǒng)更加容易維護。當然，關聯(lián)關系的缺點是比繼承關系要創(chuàng)建更多的對象。使用裝飾模式來實現(xiàn)擴展比繼承更加靈活，它以對客戶透明的方式動態(tài)地給一個對象附加更多的責任。裝飾模式可以在不需要創(chuàng)造更多子類的情況下，將對象的功能加以擴展。裝飾模式模式分析典型的抽象裝飾類代碼：publicclassDecoratorextendsComponent{

privateComponentcomponent; publicDecorator(Componentcomponent) { ponent=component; } publicvoidoperation() { component.operation(); }}裝飾模式模式分析典型的具體裝飾類代碼：publicclassConcreteDecoratorextendsDecorator{ publicConcreteDecorator(Componentcomponent) { super(component); } publicvoidoperation() { super.operation(); addedBehavior(); } publicvoidaddedBehavior() {//新增方法

}}裝飾模式模式優(yōu)缺點裝飾模式的優(yōu)點裝飾模式與繼承關系的目的都是要擴展對象的功能，但是裝飾模式可以提供比繼承更多的靈活性?？梢酝ㄟ^一種動態(tài)的方式來擴展一個對象的功能，通過配置文件可以在運行時選擇不同的裝飾器，從而實現(xiàn)不同的行為。通過使用不同的具體裝飾類以及這些裝飾類的排列組合，可以創(chuàng)造出很多不同行為的組合?？梢允褂枚鄠€具體裝飾類來裝飾同一對象，得到功能更為強大的對象。具體構件類與具體裝飾類可以獨立變化，用戶可以根據(jù)需要增加新的具體構件類和具體裝飾類，在使用時再對其進行組合，原有代碼無須改變，符合“開閉原則”。裝飾模式模式優(yōu)缺點裝飾模式的缺點使用裝飾模式進行系統(tǒng)設計時將產(chǎn)生很多小對象，這些對象的區(qū)別在于它們之間相互連接的方式有所不同，而不是它們的類或者屬性值有所不同，同時還將產(chǎn)生很多具體裝飾類。這些裝飾類和小對象的產(chǎn)生將增加系統(tǒng)的復雜度，加大學習與理解的難度。這種比繼承更加靈活機動的特性，也同時意味著裝飾模式比繼承更加易于出錯，排錯也很困難，對于多次裝飾的對象，調(diào)試時尋找錯誤可能需要逐級排查，較為煩瑣。裝飾模式模式適用環(huán)境在以下情況下可以使用裝飾模式：在不影響其他對象的情況下，以動態(tài)、透明的方式給單個對象添加職責。需要動態(tài)地給一個對象增加功能，這些功能也可以動態(tài)地被撤銷。當不能采用繼承的方式對系統(tǒng)進行擴充或者采用繼承不利于系統(tǒng)擴展和維護時。不能采用繼承的情況主要有兩類：第一類是系統(tǒng)中存在大量獨立的擴展，為支持每一種組合將產(chǎn)生大量的子類，使得子類數(shù)目呈爆炸性增長；第二類是因為類定義不能繼承（如final類）。9.6代理模式模式動機在某些情況下，一個客戶不想或者不能直接引用一個對象，此時可以通過一個稱之為“代理”的第三者來實現(xiàn)間接引用。代理對象可以在客戶端和目標對象之間起到中介的作用，并且可以通過代理對象去掉客戶不能看到的內(nèi)容和服務或者添加客戶需要的額外服務。代理模式模式動機通過引入一個新的對象（如小圖片和遠程代理對象）來實現(xiàn)對真實對象的操作或者將新的對象作為真實對象的一個替身，這種實現(xiàn)機制即為代理模式，通過引入代理對象來間接訪問一個對象，這就是代理模式的模式動機。代理模式模式定義代理模式(ProxyPattern)：給某一個對象提供一個代理，并由代理對象控制對原對象的引用。代理模式的英文叫做Proxy或Surrogate，它是一種對象結構型模式。代理模式模式結構代理模式模式結構代理模式包含如下角色：Subject:抽象主題角色Proxy:代理主題角色RealSubject:真實主題角色代理模式模式分析典型的代理類實現(xiàn)代碼：publicclassProxyimplementsSubject{privateRealSubjectrealSubject=newRealSubject();publicvoidpreRequest(){…...}publicvoidrequest(){preRequest();realSubject.request();postRequest();}publicvoidpostRequest(){……}}代理模式模式優(yōu)缺點代理模式的優(yōu)點代理模式能夠協(xié)調(diào)調(diào)用者和被調(diào)用者，在一定程度上降低了系統(tǒng)的耦合度。遠程代理使得客戶端可以訪問在遠程機器上的對象，遠程機器可能具有更好的計算性能與處理速度，可以快速響應并處理客戶端請求。虛擬代理通過使用一個小對象來代表一個大對象，可以減少系統(tǒng)資源的消耗，對系統(tǒng)進行優(yōu)化并提高運行速度。保護代理可以控制對真實對象的使用權限。代理模式模式優(yōu)缺點代理模式的缺點由于在客戶端和真實主題之間增加了代理對象，因此有些類型的代理模式可能會造成請求的處理速度變慢。實現(xiàn)代理模式需要額外的工作，有些代理模式的實現(xiàn)非常復雜。代理模式模式適用環(huán)境根據(jù)代理模式的使用目的，常見的代理模式有以下幾種類型：遠程(Remote)代理：為一個位于不同的地址空間的對象提供一個本地的代理對象，這個不同的地址空間可以是在同一臺主機中，也可是在另一臺主機中，遠程代理又叫做大使(Ambassador)。虛擬(Virtual)代理：如果需要創(chuàng)建一個資源消耗較大的對象，先創(chuàng)建一個消耗相對較小的對象來表示，真實對象只在需要時才會被真正創(chuàng)建。Copy-on-Write代理：它是虛擬代理的一種，把復制（克隆）操作延遲到只有在客戶端真正需要時才執(zhí)行。一般來說，對象的深克隆是一個開銷較大的操作，Copy-on-Write代理可以讓這個操作延遲，只有對象被用到的時候才被克隆。代理模式模式適用環(huán)境根據(jù)代理模式的使用目的，代理模式有以下幾種類型（續(xù)）：保護(ProtectorAccess)代理：控制對一個對象的訪問，可以給不同的用戶提供不同級別的使用權限。緩沖(Cache)代理：為某一個目標操作的結果提供臨時的存儲空間，以便多個客戶端可以共享這些結果。防火墻(Firewall)代理：保護目標不讓惡意用戶接近。同步化(Synchronization)代理：使幾個用戶能夠同時使用一個對象而沒有沖突。智能引用(SmartReference)代理：當一個對象被引用時，提供一些額外的操作，如將此對象被調(diào)用的次數(shù)記錄下來等。9.7享元模式模式動機面向對象技術可以很好地解決一些靈活性或可擴展性問題，但在很多情況下需要在系統(tǒng)中增加類和對象的個數(shù)。當對象數(shù)量太多時，將導致運行代價過高，帶來性能下降等問題。享元模式正是為解決這一類問題而誕生的。享元模式通過共享技術實現(xiàn)相同或相似對象的重用。享元模式模式動機在享元模式中可以共享的相同內(nèi)容稱為內(nèi)部狀態(tài)(IntrinsicState)，而那些需要外部環(huán)境來設置的不能共享的內(nèi)容稱為外部狀態(tài)(ExtrinsicState)，由于區(qū)分了內(nèi)部狀態(tài)和外部狀態(tài)，因此可以通過設置不同的外部狀態(tài)使得相同的對象可以具有一些不同的特征，而相同的內(nèi)部狀態(tài)是可以共享的。在享元模式中通常會出現(xiàn)工廠模式，需要創(chuàng)建一個享元工廠來負責維護一個享元池(FlyweightPool)用于存儲具有相同內(nèi)部狀態(tài)的享元對象。享元模式模式動機在享元模式中共享的是享元對象的內(nèi)部狀態(tài)，外部狀態(tài)需要通過環(huán)境來設置。在實際使用中，能夠共享的內(nèi)部狀態(tài)是有限的，因此享元對象一般都設計為較小的對象，它所包含的內(nèi)部狀態(tài)較少，這種對象也稱為細粒度對象。享元模式的目的就是使用共享技術來實現(xiàn)大量細粒度對象的復用。享元模式模式定義享元模式(FlyweightPattern)：運用共享技術有效地支持大量細粒度對象的復用。系統(tǒng)只使用少量的對象，而這些對象都很相似，狀態(tài)變化很小，可以實現(xiàn)對象的多次復用。由于享元模式要求能夠共享的對象必須是細粒度對象，因此它又稱為輕量級模式，它是一種對象結構型模式。享元模式模式結構享元模式模式結構享元模式包含如下角色：Flyweight:抽象享元類ConcreteFlyweight:具體享元類UnsharedConcreteFlyweight:非共享具體享元類FlyweightFactory:享元工廠類享元模式模式分析享元模式是一個考慮系統(tǒng)性能的設計模式，通過使用享元模式可以節(jié)約內(nèi)存空間，提高系統(tǒng)的性能。享元模式模式分析享元模式的核心在于享元工廠類，享元工廠類的作用在于提供一個用于存儲享元對象的享元池，用戶需要對象時，首先從享元池中獲取，如果享元池中不存在，則創(chuàng)建一個新的享元對象返回給用戶，并在享元池中保存該新增對象。

享元模式模式分析典型的享元工廠類代碼：publicclassFlyweightFactory{ privateHashMapflyweights=newHashMap();

publicFlyweightgetFlyweight(Stringkey) { if(flyweights.containsKey(key)) { return(Flyweight)flyweights.get(key); } el