課程內容7種結構型模式的基本概念、特點及其適用環境課程目的了解結構型模式的基本概念掌握7種結構型模式的特點及其適用環境熟悉和掌握類圖及其他軟件結構的表現和表達方式掌握在實際需求下應用相關設計模式的方法重點適配器模式、組合模式難點享元模式結構型模式(StructuralPattern)關注如何將現有類或對象組織在一起形成更加強大的結構不同的結構型模式從不同的角度組合類或對象，它們在盡可能滿足各種面向對象設計原則的同時為類或對象的組合提供一系列巧妙的解決方案7.1結構型模式概述7.1結構型模式概述類結構型模式關心類的組合，由多個類組合成一個更大的系統，在類結構型模式中一般只存在繼承關系和實現關系對象結構型模式關心類與對象的組合，通過關聯關系，在一個類中定義另一個類的實例對象，然后通過該對象調用相應的方法結構型模式一覽表模式名稱定

義學習難度使用頻率適配器模式(AdapterPattern)將一個類的接口轉換成客戶希望的另一個接口。適配器模式讓那些接口不兼容的類可以一起工作。★★★★★★橋接模式(BridgePattern)將抽象部分與它的實現部分解耦，使得兩者都能夠獨立變化。★★★★★★組合模式(CompositePattern)組合多個對象形成樹形結構，以表示具有部分-整體關系的層次結構。組合模式讓客戶端可以統一對待單個對象和組合對象。★★★★★★★裝飾模式(DecoratorPattern)動態地給一個對象增加一些額外的職責。就擴展功能而言，裝飾模式提供了一種比使用子類更加靈活的替代方案。★★★★★★外觀模式(FacadePattern)為子系統中的一組接口提供一個統一的入口。外觀模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。★★★★★★享元模式(FlyweightPattern)運用共享技術有效地支持大量細粒度對象的復用。★★★★★代理模式(ProxyPattern)給某一個對象提供一個代理或占位符，并由代理對象來控制對原對象的訪問。★★★★★★★7.2

適配器模式電源適配器分析現實生活：不兼容：市電220V

筆記電腦20V

引入ACAdapter（交流電適配器）軟件開發：存在不兼容的結構，例如方法名不一致引入適配器模式7.2

適配器模式適配器模式的定義將一個類的接口轉換成客戶希望的另一個接口。適配器模式讓那些接口不兼容的類可以一起工作。對象結構型模式/類結構型模式7.2.1

適配器模式的定義適配器模式的定義別名為包裝器(Wrapper)模式定義中所提及的接口是指廣義的接口，它可以表示一個方法或者方法的集合7.2.1

適配器模式的定義7.2.2適配器模式的原理與框架適配器模式的結構（類適配器）適配器模式的結構（對象適配器）適配器模式的三個角色Target（目標抽象類）定義把其他類轉換為何種接口，也就是我們的期望接口Adapter（適配器類）核心角色Adaptee（適配者類）源角色7.2.2適配器模式的原理與框架7.2.3應用案例-沒有源碼的依賴庫某軟件公司曾開發了一個依賴庫，里面包含了一些常用的文件操作。例如文件讀操作和寫操作，在進行各類軟件開發時經常需要重用該依賴庫中的算法。在為某公司開發采購管理系統時，開發人員發現需要對采購單文件進行讀寫操作；該系統的設計人員已經開發了一個文件操作接口FileOperation，在該接口中聲明了基礎讀文件方法如read(string)和寫文件方法write(string,string)。為了增強系統的健壯性，開發人員決定對讀取文件的格式進行限制并添加增量寫文件方法，需要重寫依賴庫中的讀文件算法類ReadFile和寫文件算法類WriteFile，其中ReadFile的readFile(string)方法實現了文件讀操作，WriteFile的writeFile(string,string)方法實現了文件寫操作。由于某些原因，現在公司開發人員已經找不到該依賴庫的源代碼，無法直接通過復制和粘貼操作來重用其中的代碼；部分開發人員已經針對FileOperation接口編程，如果再要求對該接口進行修改或要求大家直接使用ReadFile類和WriteFile類，將導致大量代碼需要修改。軟件公司開發人員面對這個沒有源碼的依賴庫，遇到一個令人煩惱的問題：如何在既不修改現有接口又不需要任何算法庫代碼的基礎上實現依賴庫的重用？通過分析得知，現在軟件公司面對的問題有點類似最開始所提到的電壓問題，文件操作接口FileOperation好比只支持20V電壓的筆記本，而依賴庫好比220?V的家庭用電，這兩部分都沒有辦法再進行修改，而且它們原本是兩個完全不相關的結構，如圖7-2所示。7.2.3應用案例-沒有源碼的依賴庫圖7-2需協調的兩個系統的結構示意圖實例類圖圖7-3算法庫重用結構圖7.2.3應用案例-沒有源碼的依賴庫7.2.4適配器模式的優缺點與適用環境模式優點將目標類和適配者類解耦，通過引入一個適配器類來重用現有的適配者類，無須修改原有結構增加了類的透明性和復用性，提高了適配者的復用性，同一個適配者類可以在多個不同的系統中復用靈活性和擴展性非常好類適配器模式：置換一些適配者的方法很方便對象適配器模式：可以把多個不同的適配者適配到同一個目標，還可以適配一個適配者的子類模式缺點類適配器模式：(1)一次最多只能適配一個適配者類，不能同時適配多個適配者；(2)適配者類不能為最終類；(3)目標抽象類只能為接口，不能為類對象適配器模式：在適配器中置換適配者類的某些方法比較麻煩7.2.4適配器模式的優缺點與適用環境模式適用環境系統需要使用一些現有的類，而這些類的接口不符合系統的需要，甚至沒有這些類的源代碼創建一個可以重復使用的類，用于和一些彼此之間沒有太大關聯的類，包括一些可能在將來引進的類一起工作7.2.4適配器模式的優缺點與適用環境7.3橋接模式毛筆與蠟筆的“故事”12種顏色，3種型號3支毛筆+12種顏色的調色板

36支蠟筆分析蠟筆：顏色和型號兩個不同的變化維度（即兩個不同的變化原因）耦合在一起，無論是對顏色進行擴展還是對型號進行擴展都勢必會影響另一個維度毛筆：顏色和型號實現了分離，增加新的顏色或者型號對另一方沒有任何影響7.3橋接模式分析畫筆中存在的兩個獨立變化維度示意圖7.3橋接模式在軟件開發中如何將多個變化維度分離？7.3橋接模式橋接模式的定義對象結構型模式橋接模式：將抽象部分與它的實現部分解耦，使得兩者都能夠獨立變化。7.3.1橋接模式的定義橋接模式的定義又被稱為柄體(HandleandBody)模式或接口(Interface)模式用抽象關聯取代了傳統的多層繼承將類之間的靜態繼承關系轉換為動態的對象組合關系7.3.1橋接模式的定義7.3.2橋接模式的原理與框架橋接模式的結構橋接模式的結構橋接模式包含以下4個角色：Abstraction（抽象類）RefinedAbstraction（擴充抽象類）Implementor（實現類接口）ConcreteImplementor（具體實現類）7.3.2橋接模式的原理與框架橋接模式的實現毛筆結構示意圖7.3.2橋接模式的原理與框架7.3.3應用案例-跨平臺數據處理系統實例說明某軟件公司欲開發一個跨平臺數據處理系統，要求該系統能夠讀取TXT、JSON、XML、INI等多種格式的文件，并且能夠在Windows、Linux、Android等多個操作系統上運行。系統首先將各種格式的文件內容解析為規定格式的數組，然后將數組內容顯示在屏幕上，在不同的操作系統中可以調用不同的打印函數來顯示文件內容。系統需具有較好的擴展性以支持新的文件格式和操作系統。試使用橋接模式設計該跨平臺圖像瀏覽系統。初始設計方案7.3.3應用案例-跨平臺數據處理系統兩個主要問題(1)類的個數急劇增加。在各種數據的操作系統實現層提供了12個具體類，加上各級抽象層的類，系統中類的總個數達到了17個，在該設計方案中，具體層的類的個數=所支持的數據文件格式數×所支持的操作系統數。(2)系統擴展麻煩。由于每一個具體類既包含數據文件格式信息，又包含操作系統信息，因此無論是增加新的數據文件格式還是增加新的操作系統，都需要增加大量的具體類。例如在圖7-5中增加一種新的數據文件格式YML，則需要增加3個具體類來實現該格式數據在3種不同操作系統的顯示；如果增加一個新的操作系統MacOS，為了在該操作系統下能夠顯示各種類型的數據，需要增加4個具體類。這將導致系統變得非常龐大，增加運行和維護開銷。兩個獨立變化的維度數據文件格式和操作系統改進之后的應用案例基本結構說明File充當抽象類，其子類TXTFile、JSONFile、XMLFile和INIFile充當擴充抽象類；FileImp充當實現類接口，其子類WindowsImp、LinuxImp和AndroidImp充當具體實現類。如果需要更換數據文件格式或者更換操作系統，只需修改配置文件即可，在實際使用時，可以通過分析數據文件格式后綴名來確定具體的文件格式，在程序運行時獲取操作系統信息來確定操作系統類型，無需使用配置文件。當增加新的數據文件格式或者操作系統時，原有系統無需做任何修改，只需增加一個對應的擴充抽象類或具體實現類即可，系統具有較好的可擴展性，完全符合開閉原則。7.3.4橋接模式的優缺點與適用環境模式優點分離抽象接口及其實現部分可以取代多層繼承方案，極大地減少了子類的個數提高了系統的可擴展性，在兩個變化維度中任意擴展一個維度，不需要修改原有系統，符合開閉原則模式缺點會增加系統的理解與設計難度，由于關聯關系建立在抽象層，要求開發者一開始就針對抽象層進行設計與編程正確識別出系統中兩個獨立變化的維度并不是一件容易的事情7.3.4橋接模式的優缺點與適用環境模式適用環境需要在抽象化和具體化之間增加更多的靈活性，避免在兩個層次之間建立靜態的繼承關系抽象部分和實現部分可以以繼承的方式獨立擴展而互不影響一個類存在兩個（或多個）獨立變化的維度，且這兩個（或多個）維度都需要獨立地進行擴展不希望使用繼承或因為多層繼承導致系統類的個數急劇增加的系統7.3.4橋接模式的優缺點與適用環境7.4組合模式Windows操作系統目錄結構7.4組合模式分析在樹形目錄結構中，包含文件和文件夾兩類不同的元素在文件夾中可以包含文件，還可以繼續包含子文件夾在文件中不能再包含子文件或者子文件夾文件夾

容器(Container)文件

葉子(Leaf)7.4組合模式分析當容器對象的某一個方法被調用時，將遍歷整個樹形結構，尋找也包含這個方法的成員對象并調用執行，牽一而動百，其中使用了遞歸調用的機制來對整個結構進行處理由于容器對象和葉子對象在功能上的區別，在使用這些對象的代碼中必須有區別地對待容器對象和葉子對象，而實際上大多數情況下客戶端希望一致地處理它們，因為對于這些對象的區別對待將會使程序非常復雜if(is

容器對象){

//處理容器對象}elseif(is葉子對象){//處理葉子對象}7.4組合模式如何一致地對待容器對象和葉子對象？組合模式組合模式通過一種巧妙的設計方案使得用戶可以一致性地處理整個樹形結構或者樹形結構的一部分，它描述了如何將容器對象和葉子對象進行遞歸組合，使得用戶在使用時無須對它們進行區分，可以一致地對待容器對象和葉子對象。7.4組合模式組合模式定義對象結構型模式組合模式：組合多個對象形成樹形結構以表示具有部分-整體關系的層次結構。組合模式讓客戶端可以統一對待單個對象和組合對象。7.4.1組合模式的定義組合模式定義又稱為“部分-整體”(Part-Whole)模式將對象組織到樹形結構中，可以用來描述整體與部分的關系7.4.1組合模式的定義7.4.2組合模式的原理與框架組合模式的結構組合模式的結構組合模式包含以下3個角色：Component（抽象構件）Leaf（葉子構件）Composite（容器構件）7.4.2組合模式的原理與框架7.4.3應用案例—幾何形狀繪制軟件的框架結構實例說明某軟件公司欲開發一個幾何形狀繪制軟件，該軟件既可以繪制組合圖形，也可以繪制基本形狀，如點、直線、曲線等。該幾何形狀繪制軟件還可以根據各類形狀的特點，為不同類型的幾何形狀提供不同的繪制方式，例如點(Dot)和直線(Line)的繪制方式就有所差異，如圖7-9所示。現需要提供該幾何形狀繪制軟件的整體框架設計方案。7.4.3應用案例—幾何形狀繪制軟件的框架結構一個組合形狀可以由基礎形狀結合組成，呈現出樹形目錄結構7.4.3應用案例—幾何形狀繪制軟件的框架結構7.4.3應用案例—幾何形狀繪制軟件的框架結構透明組合模式與安全組合模式透明組合模式抽象構件Component中聲明了所有用于管理成員對象的方法，包括Add()、Remove()，以及GetChild()等方法在客戶端看來，葉子對象與容器對象所提供的方法是一致的，客戶端可以一致地對待所有的對象缺點是不夠安全，因為葉子對象和容器對象在本質上是有區別的透明組合模式與安全組合模式安全組合模式抽象構件Component中沒有聲明任何用于管理成員對象的方法，而是在Composite類中聲明并實現這些方法對于葉子對象，客戶端不可能調用到這些方法缺點是不夠透明，客戶端不能完全針對抽象編程，必須有區別地對待葉子構件和容器構件7.4.4組合模式的優缺點與適用環境模式優點可以清楚地定義分層次的復雜對象，表示對象的全部或部分層次，讓客戶端忽略了層次的差異，方便對整個層次結構進行控制客戶端可以一致地使用一個組合結構或其中單個對象，不必關心處理的是單個對象還是整個組合結構，簡化了客戶端代碼增加新的容器構件和葉子構件都很方便，符合開閉原則為樹形結構的面向對象實現提供了一種靈活的解決方案模式缺點在增加新構件時很難對容器中的構件類型進行限制7.4.4組合模式的優缺點與適用環境模式適用環境在具有整體和部分的層次結構中，希望通過一種方式忽略整體與部分的差異，客戶端可以一致地對待它們在一個使用面向對象語言開發的系統中需要處理一個樹形結構在一個系統中能夠分離出葉子對象和容器對象，而且它們的類型不固定，需要增加一些新的類型7.4.4組合模式的優缺點與適用環境7.5裝飾模式現實生活中的“裝飾”實例裝飾模式分析可以在不改變一個對象本身功能的基礎上給對象增加額外的新行為是一種用于替代繼承的技術，它通過一種無須定義子類的方式給對象動態增加職責，使用對象之間的關聯關系取代類之間的繼承關系引入了裝飾類，在裝飾類中既可以調用待裝飾的原有類的方法，還可以增加新的方法，以擴展原有類的功能7.5裝飾模式7.5.1裝飾模式的定義裝飾模式的定義對象結構型模式裝飾模式：動態地給一個對象增加一些額外的職責。就擴展功能而言，裝飾模式提供了一種比使用子類更加靈活的替代方案。DecoratorPattern:Attachadditionalresponsibilitiestoanobjectdynamically.Decoratorsprovideaflexiblealternativetosubclassingforextendingfunctionality.裝飾模式的定義以對客戶透明的方式動態地給一個對象附加上更多的責任可以在不需要創建更多子類的情況下，讓對象的功能得以擴展7.5.1裝飾模式的定義7.5.2裝飾模式的原理與框架裝飾模式的結構裝飾模式的結構裝飾模式包含以下4個角色：Component（抽象構件）ConcreteComponent（具體構件）Decorator（抽象裝飾類）ConcreteDecorator（具體裝飾類）7.5.2裝飾模式的原理與框架7.5.3應用案例—文件管理工具實例說明某軟件公司基于面向對象技術開發了一套文件管理工具FileManager。該工具提供了大量基本文件操作，如打開文件、讀寫文件等。由于在使用工具時，用戶經常要求定制一些特效顯示效果，如文件壓縮、文件加密、既加密又壓縮文件等等，因此經常需要對該工具進行擴展以增強其功能。文件管理工具功能示意圖如圖所示裝飾模式的解決方案實例類圖圖7-14文件管理工具結構圖透明裝飾模式與半透明裝飾模式透明裝飾模式透明(Transparent)裝飾模式：要求客戶端完全針對抽象編程，裝飾模式的透明性要求客戶端程序不應該將對象聲明為具體構件類型或具體裝飾類型，而應該全部聲明為抽象構件類型對于客戶端而言，具體構件對象和具體裝飾對象沒有任何區別透明裝飾模式與半透明裝飾模式透明裝飾模式可以讓客戶端透明地使用裝飾之前的對象和裝飾之后的對象，無須關心它們的區別可以對一個已裝飾過的對象進行多次裝飾，得到更為復雜、功能更為強大的對象無法在客戶端單獨調用新增方法AddedBehavior()……Componentcomponent_o,component_d1,component_d2;//全部使用抽象構件定義component_o=newConcreteComponent();component_d1=newConcreteDecorator1(component_o);component_d2=newConcreteDecorator2(component_d1);component_d2.Operation();//無法單獨調用component_d2的AddedBehavior()方法……透明裝飾模式與半透明裝飾模式半透明裝飾模式半透明(Semi-transparent)裝飾模式：用具體裝飾類型來定義裝飾之后的對象，而具體構件使用抽象構件類型來定義對于客戶端而言，具體構件類型無須關心，是透明的；但是具體裝飾類型必須指定，這是不透明的透明裝飾模式與半透明裝飾模式半透明裝飾模式可以給系統帶來更多的靈活性，設計相對簡單，使用起來也非常方便客戶端使用具體裝飾類型來定義裝飾后的對象，因此可以單獨調用AddedBehavior()方法最大的缺點在于不能實現對同一個對象的多次裝飾，而且客戶端需要有區別地對待裝飾之前的對象和裝飾之后的對象……Componentcomponent_o;//使用抽象構件類型定義component_o=newConcreteComponent();component_o.Operation();ConcreteDecoratorcomponent_d;//使用具體裝飾類型定義component_d=newConcreteDecorator(component_o);component_d.Operation();component_d.AddedBehavior();//單獨調用新增業務方法……7.5.4裝飾模式的優缺點與適用環境模式優點對于擴展一個對象的功能，裝飾模式比繼承更加靈活，不會導致類的個數急劇增加可以通過一種動態的方式來擴展一個對象的功能，通過配置文件可以在運行時選擇不同的具體裝飾類，從而實現不同的行為可以對一個對象進行多次裝飾具體構件類與具體裝飾類可以獨立變化，用戶可以根據需要增加新的具體構件類和具體裝飾類，且原有類庫代碼無須改變，符合開閉原則模式缺點使用裝飾模式進行系統設計時將產生很多小對象，大量小對象的產生勢必會占用更多的系統資源，在一定程度上影響程序的性能比繼承更加易于出錯，排錯也更困難，對于多次裝飾的對象，調試時尋找錯誤可能需要逐級排查，較為煩瑣7.5.4裝飾模式的優缺點與適用環境模式適用環境在不影響其他對象的情況下，以動態、透明的方式給單個對象添加職責當不能采用繼承的方式對系統進行擴展或者采用繼承不利于系統擴展和維護時可以使用裝飾模式7.5.4裝飾模式的優缺點與適用環境7.6外觀模式兩種喝茶方式示意圖分析一個客戶類需要和多個業務類交互，而這些需要交互的業務類經常會作為一個整體出現引入一個新的外觀類(Facade)來負責和多個業務類【子系統(Subsystem)】進行交互，而客戶類只需與外觀類交互為多個業務類的調用提供了一個統一的入口，簡化了類與類之間的交互7.6外觀模式分析沒有外觀類：每個客戶類需要和多個子系統之間進行復雜的交互，系統的耦合度將很大引入外觀類：客戶類只需要直接與外觀類交互，客戶類與子系統之間原有的復雜引用關系由外觀類來實現，從而降低了系統的耦合度7.6外觀模式分析一個子系統的外部與其內部的通信通過一個統一的外觀類進行，外觀類將客戶類與子系統的內部復雜性分隔開，使得客戶類只需要與外觀角色打交道，而不需要與子系統內部的很多對象打交道7.6外觀模式7.6.1外觀模式的定義外觀模式的定義對象結構型模式外觀模式：為子系統中的一組接口提供一個統一的入口。外觀模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。外觀模式的定義又稱為門面模式是迪米特法則的一種具體實現通過引入一個新的外觀角色來降低原有系統的復雜度，同時降低客戶類與子系統的耦合度所指的子系統是一個廣義的概念，它可以是一個類、一個功能模塊、系統的一個組成部分或者一個完整的系統7.6.1外觀模式的定義7.6.2外觀模式的原理與框架外觀模式的結構外觀模式的結構外觀模式包含以下2個角色：Facade（外觀角色）SubSystem（子系統角色）7.6.2外觀模式的原理與框架7.6.3應用案例——視頻解碼模塊某軟件公司欲開發一個可應用于多個軟件的視頻解碼模塊，該模塊可以對文件中的數據進行加密，并將加密之后的數據存儲在一個新文件中。具體的流程包括三個部分，分別是讀取源文件、視頻解碼、保存解碼之后的文件，其中，讀取視頻文件和保存視頻文件使用流來實現，解碼操作通過相應的視頻解碼算法實現。這三個操作相對獨立，為了實現代碼的獨立重用，讓設計更符合單一職責原則，這三個操作的業務代碼封裝在三個不同的類中實例類圖圖7-17視頻解碼模塊結構圖7.6.3應用案例——視頻解碼模塊7.6.4外觀模式的優缺點與適用環境模式優點它對客戶端屏蔽了子系統組件，減少了客戶端所需處理的對象數目，并使得子系統使用起來更加容易它實現了子系統與客戶端之間的松耦合關系，這使得子系統的變化不會影響到調用它的客戶端，只需要調整外觀類即可一個子系統的修改對其他子系統沒有任何影響，而且子系統的內部變化也不會影響到外觀對象模式缺點不能很好地限制客戶端直接使用子系統類，如果對客戶端訪問子系統類做太多的限制則減少了可變性和靈活性如果設計不當，增加新的子系統可能需要修改外觀類的源代碼，違背了開閉原則7.6.4外觀模式的優缺點與適用環境模式適用環境要為訪問一系列復雜的子系統提供一個簡單入口客戶端程序與多個子系統之間存在很大的依賴性在層次化結構中，可以使用外觀模式的定義系統中每一層的入口，層與層之間不直接產生聯系，而是通過外觀類建立聯系，降低層之間的耦合度7.6.4外觀模式的優缺點與適用環境7.7享元模式動機如果一個軟件系統在運行時所創建的相同或相似對象數量太多，將導致運行代價過高，帶來系統資源浪費、性能下降等問題如何避免系統中出現大量相同或相似的對象，同時又不影響客戶端程序通過面向對象的方式對這些對象進行操作呢？7.7享元模式字符享元對象示意圖分析享元模式：通過共享技術實現相同或相似對象的重用享元池(FlyweightPool)：存儲共享實例對象的地方7.7享元模式分析內部狀態(IntrinsicState)：存儲在享元對象內部并且不會隨環境改變而改變的狀態，內部狀態可以共享（例如：字符的內容）外部狀態(ExtrinsicState)：隨環境改變而改變的、不可以共享的狀態。享元對象的外部狀態通常由客戶端保存，并在享元對象被創建之后，需要使用的時候再傳入到享元對象內部。一個外部狀態與另一個外部狀態之間是相互獨立的（例如：字符的顏色和大小）7.7享元模式原理(1)將具有相同內部狀態的對象存儲在享元池中，享元池中的對象是可以實現共享的(2)需要的時候將對象從享元池中取出，即可實現對象的復用(3)通過向取出的對象注入不同的外部狀態，可以得到一系列相似的對象，而這些對象在內存中實際上只存儲一份7.7享元模式享元模式的定義對象行為型模式享元模式：運用共享技術有效地支持大量細粒度對象的復用。FlyweightPattern:Usesharingtosupportlargenumbersoffine-grainedobjectsefficiently.7.7.1享元模式的定義享元模式的定義又稱為輕量級模式要求能夠被共享的對象必須是細粒度對象7.7.1享元模式的定義7.7.2享元模式的原理與框架享元模式的結構享元模式的結構享元模式包含以下4個角色：Flyweight（抽象享元類）ConcreteFlyweight（具體享元類）UnsharedConcreteFlyweight（非共享具體享元類）FlyweightFactory（享元工廠類）7.7.2享元模式的原理與框架7.7.3應用實例實例說明某軟件公司欲開發一個飛機大戰游戲，其界面效果如圖7-19所示。軟件公司開發人員通過對該游戲進行分析，發現在飛機發射的子彈中包含大量重復單元。它們的運動方向、繪制方式都一模一樣，只是子彈的類型不同而已。如果將每一個子彈都作為一個獨立的對象存儲在內存中，將導致該飛機大戰游戲在運行時所需內存空間較大。如何降低運行代價，提高系統性能，是公司開發人員需要解決的一個問題。圖7-19圍棋軟件界面效果圖實例類圖圖7-20飛機大戰游戲重的子彈基本結構圖7.7.3應用實例IgoBullet充當抽象享元類BlackIgoBullet和WhiteIgoBullet充當具體享元類IgoBulletFactory充當享元工廠類7.7.3應用實例結果及分析在實現享元工廠類時使用了單例模式和簡單工廠模式，確保了享元工廠對象的唯一性，并提供了工廠方法向客戶端返回享元對象7.7.3應用實例單純享元模式和復合享元模式單純享元模式所有的具體享元類都是可以共享的，不存在非共享具體享元類復合享元模式將一些單純享元對象使用組合模式加以組合如果希望為多個內部狀態不同的享元對象設置相同的外部狀態，可以考慮使用復合享元模式單純享元模式和復合享元模式7.7.4享元模式的優缺點與適用環境模式優點可以減少內存中對象的數量，使得相同或者相似的對象在內存中只保存一份，從而可以節約系統資源，提高系統性能外部狀態相對獨立，而且不會影響其內部狀態，從而使得享元對象可以在不同的環境中被共享模式缺點使得系統變得復雜，需要分離出內部狀態和外部狀態，這使得程序的邏輯復雜化為了使對象可以共享，享元模式需要將享元對象的部分狀態外部化，而讀取外部狀態將使得運行時間變長7.7.4享元模式的優缺點與適用環境模式適用環境一個系統有大量相同或者相似的對象，造成內存的大量耗費對象的大部分狀態都可以外部化，可以將這些外部狀態傳入對象中在使用享元模式時需要維護一個存儲享元對象的享元池，而這需要耗費一定的系統資源，因此，在需要多次重復使用享元對象時才值得使用享元模式7.7.4享元模式的優缺點與適用環境7.8代理模式商品代購示意圖分析代購商品：顧客

代購網站

商品軟件開發：客戶端

代理對象

真實對象客戶端代理對象真實對象7.8代理模式類型遠程代理保護代理虛擬代理緩沖代理智能引用代理……7.8代理模式代理模式的定義對象結構型模式代理模式：給某一個對象提供一個代理或占位符，并由代理對象來控制對原對象的訪問。7.8.1代理模式的定義代理模式的定義引入一個新的代理對象代理對象在客戶端對象和目標對象之間起到中介的作用去掉客戶不能看到的內容和服務或者增添客戶需要的額外的新服務7.8.1代理模式的定義7.8.2代理模式的原理與框架代理模式的結構代理模式的結構代理模式包含以下3個角色：Subject（抽象主題角色）Proxy（代理主題角色）RealSubject（真實主題角色）7.8.2代理模式的原理與框架幾種常見的代理模式遠程代理(RemoteProxy)：為一個位于不同的地址空間的對象提供一個本地的代理對象，這個不同的地址空間可以在同一臺主機中，也可以在另一臺主機中，遠程代理又稱為大使(Ambassador)虛擬代理(VirtualProxy)：如果需要創建一個資源消耗較大的對象，先創建一個消耗相對較小的對象來表示，真實對象只在需要時才會被真正創建7.8.2代理模式的原理與框架幾種常見的代理模式保護代理(ProtectProxy)：控制對一個對象的訪問，可以給不同的用戶提供不同級別的使用權限緩沖代理(CacheProxy)：為某一個目標操作的結果提供臨時的存儲空間，以便多個客戶端可以共享這些結果智能引用代理(Smart