23種設(shè)計(jì)模式可以在功能設(shè)計(jì)，功能的編程實(shí)現(xiàn)設(shè)計(jì)，程序結(jié)構(gòu)優(yōu)化和性能優(yōu)化等方面給我們以幫助。大部分模式我們?cè)诰幊痰倪^(guò)程中都已經(jīng)無(wú)意識(shí)的使用過(guò)。每一個(gè)模式描述了一個(gè)在我們周?chē)粩嘀貜?fù)發(fā)生的問(wèn)題，以及該問(wèn)題的解決方案的核心。這是面向?qū)ο缶幊倘藛T必須掌握的一門(mén)內(nèi)功。設(shè)計(jì)模式描述了軟件設(shè)計(jì)過(guò)程中某一類(lèi)常見(jiàn)問(wèn)題的一般性的解決方案。面向?qū)ο笤O(shè)計(jì)模式描述了面向?qū)ο笤O(shè)計(jì)過(guò)程中、特定場(chǎng)景下、類(lèi)與相互通信的對(duì)象之間常見(jiàn)的組織關(guān)系。整個(gè)設(shè)計(jì)模式貫穿一個(gè)原理:面對(duì)接口編程，而不是面對(duì)實(shí)現(xiàn).目標(biāo)原則是:降低耦合,增強(qiáng)靈活性. 1.1. 創(chuàng)建型創(chuàng)建型：負(fù)責(zé)對(duì)象創(chuàng)建。1、 Singleton，單例模式：定義：保證一個(gè)類(lèi)只有一個(gè)實(shí)例，并提供一個(gè)訪問(wèn)它的全局訪問(wèn)點(diǎn) 。單例模式有延遲初始化和非延遲兩種實(shí)現(xiàn)方式。單體模式注意事項(xiàng)：有時(shí)在某些情況下，使用Singleton并不能達(dá)到Singleton的目的，如有多個(gè)Singleton對(duì)象同時(shí)被不同的類(lèi)裝入器裝載；在EJB這樣的分布式系統(tǒng)中使用也要注意這種情況，因?yàn)镋JB是跨服務(wù)器，跨JVM的。Singleton模式看起來(lái)簡(jiǎn)單，使用方法也很方便，但是真正用好，是非常不容易，需要對(duì)Java的類(lèi) 線程 內(nèi)存等概念有相當(dāng)?shù)牧私狻？傊喝绻愕膽?yīng)用基于容器，那么Singleton模式少用或者不用，可以使用相關(guān)替代技術(shù)。二、Abstract Factory，抽象工廠模式又稱(chēng)為工具箱，產(chǎn)生產(chǎn)品族，但不利于產(chǎn)生新的產(chǎn)品。定義：提供一個(gè)接口，讓該接口負(fù)責(zé)創(chuàng)建一系列“相關(guān)或者相互依賴(lài)的對(duì)象”，無(wú)需指定它們具體的類(lèi)。面向?qū)ο蟮脑O(shè)計(jì)中，我們使用“new”的方式來(lái)創(chuàng)建對(duì)象，這樣的問(wèn)題就是：我們依賴(lài)實(shí)現(xiàn)，不能應(yīng)對(duì)“具體實(shí)例化類(lèi)型”的變化。變化點(diǎn)在“對(duì)象創(chuàng)建”，因此就封裝“對(duì)象創(chuàng)建”，面向接口編程依賴(lài)接口，而非依賴(lài)實(shí)現(xiàn)。AbstractFactory模式的幾個(gè)要點(diǎn)1.如果沒(méi)有應(yīng)對(duì)“多系列對(duì)象創(chuàng)建”的需求變化，則沒(méi)有必要使用AbstractFactory模式，這時(shí)候使用簡(jiǎn)單的靜態(tài)工廠完全可以。2.系列對(duì)象指的是這些對(duì)象之間有相互依賴(lài)、或作用的關(guān)系，例如游戲開(kāi)發(fā)場(chǎng)景中“道路”與“房屋”的依賴(lài)，“道路”與“地道”的依賴(lài)。3.AbstractFactory模式主要在于應(yīng)對(duì)“新系列”的需求變動(dòng)。其缺點(diǎn)在于難以應(yīng)對(duì)“新對(duì)象”的需求變動(dòng)。4.AbstractFactory模式經(jīng)常和FactoryMethod模式共同組合來(lái)應(yīng)對(duì)“對(duì)象創(chuàng)建”的需求變化。（FactoryMethod是應(yīng)對(duì)對(duì)象的變化，）Builder模式和AbstractFactory模式的區(qū)別Builder模式更強(qiáng)調(diào)的是對(duì)象部分的“構(gòu)建”這樣一個(gè)嚴(yán)格的過(guò)程，它構(gòu)建的是整個(gè)對(duì)象的各個(gè)部分。它把構(gòu)建穩(wěn)定下來(lái)之后，各個(gè)部分在變化，最后組合成一個(gè)整體的對(duì)象。AbstractFactory模式構(gòu)建的是一組系列交互的對(duì)象?；ハ嘁蕾?lài)、互相交互的對(duì)象和一個(gè)對(duì)象的各個(gè)部分是有區(qū)別的。三、Factory Method，工廠方法模式又稱(chēng)為多形性工廠；定義：一個(gè)用于創(chuàng)建對(duì)象的接口，讓子類(lèi)決定實(shí)例化哪一個(gè)類(lèi)，F(xiàn)actory Method使一個(gè)類(lèi)的實(shí)例化延遲到了子類(lèi)。 1) 抽象工廠角色（AbstractCreator）：這是工廠方法模式的核心，它與應(yīng)用程序無(wú)關(guān)。是具體工廠角色必須實(shí)現(xiàn)的接口或者必須繼承的父類(lèi)。在java中它由抽象類(lèi)或者接口來(lái)實(shí)現(xiàn)。2) 具體工廠角色(Creator)：它含有和具體業(yè)務(wù)邏輯有關(guān)的代碼。由應(yīng)用程序調(diào)用以創(chuàng)建對(duì)應(yīng)的具體產(chǎn)品的對(duì)象。3) 抽象產(chǎn)品角色(AbstractProduct)：它是具體產(chǎn)品繼承的父類(lèi)或者是實(shí)現(xiàn)的接口。在java中一般有抽象類(lèi)或者接口來(lái)實(shí)現(xiàn)。4) 具體產(chǎn)品角色(Product)：具體工廠角色所創(chuàng)建的對(duì)象就是此角色的實(shí)例。在java中由具體的類(lèi)來(lái)實(shí)現(xiàn)。四、Builder，建造模式建造模式，又叫生成器模式。定義:將一個(gè)復(fù)雜對(duì)象的構(gòu)建與它的表示分離,使得同樣的構(gòu)建過(guò)程可以創(chuàng)建不同的表示.Builder模式主要用于“分步驟構(gòu)建一個(gè)復(fù)雜的對(duì)象”。在這其中“分步驟”是一個(gè)穩(wěn)定的算法（即Director），而復(fù)雜對(duì)象的各個(gè)部分（即ConcreteBuilder）則經(jīng)常變化。變化點(diǎn)在哪里，封裝哪里Builder模式主要在于應(yīng)對(duì)“復(fù)雜對(duì)象各個(gè)部分”的頻繁需求變動(dòng)。其缺點(diǎn)在于難以應(yīng)對(duì)“分步驟構(gòu)建算法”的需求變動(dòng)。（例如房屋構(gòu)造如果經(jīng)常改變，那么這個(gè)Builder模式也沒(méi)有意義了）AbstractFactory模式解決“系列對(duì)象”的需求變化，Builder模式解決“對(duì)象部分”的需求變化。Builder模式通常和Composite模式組合使用。應(yīng)用舉例：數(shù)據(jù)庫(kù)連接池（每一個(gè)連接的重用）五、Prototype，原始模型模式定義：用原型實(shí)例指定創(chuàng)建對(duì)象的種類(lèi)，并且通過(guò)拷貝這些原型來(lái)創(chuàng)建新的對(duì)象。 通過(guò)給出一個(gè)原型對(duì)象來(lái)指明所要?jiǎng)?chuàng)建的對(duì)象的類(lèi)型，然后用復(fù)制這個(gè)原型對(duì)象的方法創(chuàng)建出更多同類(lèi)型的對(duì)象。原始模型模式允許動(dòng)態(tài)的增加或減少產(chǎn)品類(lèi)，產(chǎn)品類(lèi)不需要非得有任何事先確定的等級(jí)結(jié)構(gòu)，原始模型模式適用于任何的等級(jí)結(jié)構(gòu)。缺點(diǎn)是每一個(gè)類(lèi)都必須配備一個(gè)克隆方法。在Java中Prototype模式變成clone()方法的使用，由于Java的純潔的面向?qū)ο筇匦裕沟迷贘ava中使用設(shè)計(jì)模式變得很自然，兩者已經(jīng)幾乎是渾然一體了。這反映在很多模式上，如Interator遍歷模式。1.2. 行為型行為型：類(lèi)與對(duì)象交互中的職責(zé)分配。六、Iterator，迭代器模式：迭代器模式，又叫游標(biāo)模式，定義:提供一種方法訪問(wèn)一個(gè)容器（container）對(duì)象中各個(gè)元素，而又不需暴露該對(duì)象的內(nèi)部細(xì)節(jié)。這個(gè)模式已經(jīng)被整合入Java的Collection.在大多數(shù)場(chǎng)合下無(wú)需自己制造一個(gè)Iterator,只要將對(duì)象裝入Collection中，直接使用Iterator進(jìn)行對(duì)象遍歷1) 迭代器角色（Iterator）：迭代器角色負(fù)責(zé)定義訪問(wèn)和遍歷元素的接口。（Iterator）2) 具體迭代器角色（Concrete Iterator）：具體迭代器角色要實(shí)現(xiàn)迭代器接口，并要記錄遍歷中的當(dāng)前位置。3) 容器角色（Container）：容器角色負(fù)責(zé)提供創(chuàng)建具體迭代器角色的接口。4) 具體容器角色（Concrete Container）：具體容器角色實(shí)現(xiàn)創(chuàng)建具體迭代器角色的接口。多個(gè)對(duì)象聚在一起形成的總體稱(chēng)之為聚合，聚合對(duì)象是能夠包容一組對(duì)象的容器對(duì)象。迭代模式將迭代邏輯封裝到一個(gè)獨(dú)立的子對(duì)象中，從而與聚合本身隔開(kāi)。迭代子模式簡(jiǎn)化了聚合的界面。每一個(gè)聚合對(duì)象都可以有一個(gè)或一個(gè)以上的迭代子對(duì)象，每一個(gè)迭代子的迭代狀態(tài)可以是彼此獨(dú)立的。迭代算法可以獨(dú)立于聚合角色變化。七、Observer，觀察者模式：定義：定義對(duì)象間的一種一對(duì)多的依賴(lài)關(guān)系，以便當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí)，所有依賴(lài)于它的對(duì)象都得到通知并自動(dòng)更新。觀察者模式定義了一種一隊(duì)多的依賴(lài)關(guān)系，讓多個(gè)觀察者對(duì)象（observer Object）同時(shí)監(jiān)聽(tīng)某一個(gè)主題對(duì)象(subject Object)。這個(gè)主題對(duì)象在狀態(tài)上發(fā)生變化時(shí)，會(huì)通知所有觀察者對(duì)象，使他們能夠自動(dòng)更新自己。應(yīng)用舉例：電子商務(wù)中，商品的變化，通知關(guān)注的用戶(hù)。Java的API還為為我們提供現(xiàn)成的Observer接口Java.util.Observer,八、Template Method，模板方法模式定義:定義一個(gè)操作中算法的骨架,將一些步驟的執(zhí)行延遲到其子類(lèi)中. Template Method使得子類(lèi)可以不改變一個(gè)算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟。介紹：變化是軟件設(shè)計(jì)的永恒主題，如何管理變化帶來(lái)的復(fù)雜性？設(shè)計(jì)模式的藝術(shù)性和復(fù)雜度就在于如何分析，并發(fā)現(xiàn)系統(tǒng)中的變化點(diǎn)和穩(wěn)定點(diǎn)，并使用特定的設(shè)計(jì)方法來(lái)應(yīng)對(duì)這種變化.如果你只想掌握一種設(shè)計(jì)模式，那么它就是Template Method！Template Method模式是一種非?；A(chǔ)性的設(shè)計(jì)模式，在面向?qū)ο笙到y(tǒng)中有著大量的應(yīng)用。它用最簡(jiǎn)潔的機(jī)制（虛函數(shù)的多態(tài)性）為很多應(yīng)用程序框架提供了靈活的擴(kuò)展，是代碼復(fù)用方面的基本實(shí)現(xiàn)結(jié)構(gòu)。模板方法模式準(zhǔn)備一個(gè)抽象類(lèi)，將部分邏輯以具體方法以及具體構(gòu)造方法的形式實(shí)現(xiàn)，然后聲明一些抽象方法來(lái)迫使子類(lèi)實(shí)現(xiàn)剩余的邏輯。不同的子類(lèi)可以以不同的方式實(shí)現(xiàn)這些抽象方法，從而對(duì)剩余的邏輯有不同的實(shí)現(xiàn)。先制定一個(gè)頂級(jí)邏輯框架，而將邏輯的細(xì)節(jié)留給具體的子類(lèi)去實(shí)現(xiàn)。應(yīng)用舉例：九、Command，命令模式：定義：將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，從而使你可用不同的請(qǐng)求對(duì)客戶(hù)（客戶(hù)程序，也是行為的請(qǐng)求者）進(jìn)行參數(shù)化；對(duì)請(qǐng)求排隊(duì)或記錄請(qǐng)求日志，以及支持可撤銷(xiāo)的操作。Command：定義命令的接口，聲明執(zhí)行的方法。ConcreteCommand：命令接口實(shí)現(xiàn)對(duì)象，是“虛”的實(shí)現(xiàn)；通常會(huì)持有接收者，并調(diào)用接收者的功能來(lái)完成命令要執(zhí)行的操作。Receiver：接收者，真正執(zhí)行命令的對(duì)象。任何類(lèi)都可能成為一個(gè)接收者，只要它能夠?qū)崿F(xiàn)命令要求實(shí)現(xiàn)的相應(yīng)功能。Invoker： 要求命令對(duì)象執(zhí)行請(qǐng)求，通常會(huì)持有命令對(duì)象，可以持有很多的命令對(duì)象。這個(gè)是客戶(hù)端真正觸發(fā)命令并要求命令執(zhí)行相應(yīng)操作的地方，也就是說(shuō)相當(dāng)于使用命令對(duì)象的入口。Client：創(chuàng)建具體的命令對(duì)象，并且設(shè)置命令對(duì)象的接收者。注意這個(gè)不是我們常規(guī)意義上的客戶(hù)端，而是在組裝命令對(duì)象和接收者，或許，把這個(gè)Client稱(chēng)為裝配者會(huì)更好理解，因?yàn)檎嬲褂妹畹目蛻?hù)端是從Invoker來(lái)觸發(fā)執(zhí)行。命令模式把一個(gè)請(qǐng)求或者操作封裝到一個(gè)對(duì)象中。命令模式把發(fā)出命令的責(zé)任和執(zhí)行命令的責(zé)任分割開(kāi)，委派給不同的對(duì)象。命令模式允許請(qǐng)求的一方和發(fā)送的一方獨(dú)立開(kāi)來(lái)，使得請(qǐng)求的一方不必知道接收請(qǐng)求的一方的接口，更不必知道請(qǐng)求是怎么被接收，以及操作是否執(zhí)行，何時(shí)被執(zhí)行以及是怎么被執(zhí)行的。系統(tǒng)支持命令的撤消。命令模式解決的問(wèn)題：在軟件構(gòu)建過(guò)程中，“行為請(qǐng)求者”與“行為實(shí)現(xiàn)者”通常呈現(xiàn)一種“緊耦合”。但在某些場(chǎng)合比如需要對(duì)行為進(jìn)行“記錄、撤銷(xiāo)/重做（undo/redo）、事務(wù)”等處理，這種無(wú)法抵御變化的緊耦合是不合適的。在這種情況下，如何將“行為請(qǐng)求者”與“行為實(shí)現(xiàn)者”解耦？將一組行為抽象為對(duì)象，可以實(shí)現(xiàn)二者之間的松耦合。命令模式的要點(diǎn)：Command模式的根本目的在于將“行為請(qǐng)求者”與“行為實(shí)現(xiàn)者”解耦，在面向?qū)ο笳Z(yǔ)言中，常見(jiàn)的實(shí)現(xiàn)手段是“將行為抽象為對(duì)象”。實(shí)現(xiàn)Command接口的具體命令對(duì)象ConcreteCommand有時(shí)候根據(jù)需要可能會(huì)保存一些額外的狀態(tài)信息。通過(guò)使用Composite模式，可以將多個(gè)“命令”封裝為一個(gè)“復(fù)合命令”MacroCommand。應(yīng)用舉例：調(diào)度服務(wù)器，activeMQ服務(wù)器，監(jiān)測(cè)點(diǎn)客戶(hù)端。十、State，狀態(tài)模式：定義: 不同的狀態(tài),不同的行為;或者說(shuō),每個(gè)狀態(tài)有著相應(yīng)的行為。 狀態(tài)改變引起行為改變狀態(tài)模式允許一個(gè)對(duì)象在其內(nèi)部狀態(tài)改變的時(shí)候改變行為，這個(gè)對(duì)象看上去象是改變了它的類(lèi)一樣。狀態(tài)模式把所研究的對(duì)象的行為包裝在不同的狀態(tài)對(duì)象里，每一個(gè)狀態(tài)對(duì)象都屬于一個(gè)抽象狀態(tài)類(lèi)的一個(gè)子類(lèi)。1) 使用環(huán)境（Context）角色：客戶(hù)程序是通過(guò)它來(lái)滿足自己的需求。它定義了客戶(hù)程序需要的接口；并且維護(hù)一個(gè)具體狀態(tài)角色的實(shí)例，這個(gè)實(shí)例來(lái)決定當(dāng)前的狀態(tài)。2) 狀態(tài)（State）角色：定義一個(gè)接口以封裝與使用環(huán)境角色的一個(gè)特定狀態(tài)以及和這個(gè)特定狀態(tài)相關(guān)的行為。3) 具體狀態(tài)（Concrete State）角色：實(shí)現(xiàn)狀態(tài)角色定義的接口。類(lèi)圖，結(jié)構(gòu)非常簡(jiǎn)單也與策略模式非常相似。狀態(tài)模式的意圖是讓一個(gè)對(duì)象在其內(nèi)部狀態(tài)改變的時(shí)候，其行為也隨之改變。狀態(tài)模式需要對(duì)每一個(gè)系統(tǒng)可能取得的狀態(tài)創(chuàng)立一個(gè)狀態(tài)類(lèi)的子類(lèi)。當(dāng)系統(tǒng)的狀態(tài)變化時(shí)，系統(tǒng)便改變所選的子類(lèi)。應(yīng)用舉例：hibernate的對(duì)象持久化，登錄用戶(hù)鎖定，PS中工具箱等。優(yōu)缺點(diǎn)：1)優(yōu)點(diǎn): 避免了為判斷狀態(tài)而產(chǎn)生的巨大的if或case語(yǔ)句。 將對(duì)象行為交給狀態(tài)類(lèi)維護(hù)后，對(duì)于上層程序而言，僅需要維護(hù)狀態(tài)之間的轉(zhuǎn)換規(guī)則。2)會(huì)導(dǎo)致某些系統(tǒng)有過(guò)多的具體狀態(tài)類(lèi)。適用性1）一個(gè)對(duì)象的行為取決于它的狀態(tài)，并且它必須在運(yùn)行時(shí)刻根據(jù)狀態(tài)改變它的行為。2）一個(gè)對(duì)象含有龐大的條件分支語(yǔ)句，這些分支依賴(lài)于它的狀態(tài)。這個(gè)狀態(tài)通常用一個(gè)或多個(gè)枚舉常量表示。通常有多個(gè)操作包含這一相同的結(jié)構(gòu)。State模式將每一個(gè)分支放入一個(gè)獨(dú)立的類(lèi)中。這使得你可以根據(jù)對(duì)象自身的情況將對(duì)象的狀態(tài)作為一個(gè)對(duì)象，這一對(duì)象可以不依賴(lài)于其他對(duì)象而獨(dú)立變化。十一、Strategy，策略模式：定義：定義一系列的算法，把他們一個(gè)個(gè)封裝起來(lái)，并使他們可以互相替換，此模式使得算法可以獨(dú)立于使用它們的客戶(hù)。 l Strategy及其子類(lèi)為組件提供了一系列可重用的算法策略模式針對(duì)一組算法，將每一個(gè)算法封裝（封裝性）到具有共同接口的獨(dú)立的類(lèi)中，從而可以使得類(lèi)型在運(yùn)行時(shí)方便地根據(jù)需要在各個(gè)算法之間進(jìn)行切換，使得算法可以在不影響到客戶(hù)端的情況下發(fā)生變化（透明性）。l 算法與對(duì)象本身解耦策略模式把行為和環(huán)境分開(kāi)。環(huán)境類(lèi)負(fù)責(zé)維持和查詢(xún)行為類(lèi)，各種算法在具體的策略類(lèi)中提供。由于算法和環(huán)境獨(dú)立開(kāi)來(lái)，算法的增減，修改都不會(huì)影響到環(huán)境和客戶(hù)端。l Strategy類(lèi)型里面不攜帶狀態(tài)信息Strategy類(lèi)型里面不攜帶狀態(tài)信息（這是與模板方法的區(qū)別，模板方法本身是攜帶狀態(tài)信息的），我們不能把它看成一種實(shí)例，即使有狀態(tài)，也是會(huì)通過(guò)參數(shù)傳入。l Strategy是獨(dú)立的一個(gè)Strategy定義了一個(gè)算法的完整步驟和結(jié)構(gòu)，只要用一個(gè)Strategy具體類(lèi)，就可以完成整個(gè)算法的操作，不會(huì)有其它依賴(lài)和耦合。l Strategy模式提供了用條件判斷語(yǔ)句以外的另一種選擇，消除條件判斷語(yǔ)句，就是在解耦合。含有許多條件判斷語(yǔ)句的代碼通常都需要Strategy模式。l 與State類(lèi)似，如果Strategy對(duì)象沒(méi)有實(shí)例變量，那么各個(gè)上下文可以共享一個(gè)Strategy對(duì)象，從而節(jié)省對(duì)象開(kāi)銷(xiāo)。l Strategy模式適用的是算法結(jié)構(gòu)中整個(gè)算法的改變，而不是算法中某個(gè)部分的改變。策略模式和模版模式的區(qū)別：1）策略模式針對(duì)的是一個(gè)整個(gè)算法改變。模版模式針對(duì)的是算法中某個(gè)或某幾個(gè)部分的改變。2）策略模式是把行為和環(huán)境分開(kāi)；而模版模式是把行為和行為實(shí)現(xiàn)延遲。應(yīng)用舉例：以不同的格式保存文件, 以不同的算法壓縮文件,截取不同形狀的圖片等。十二、China of Responsibility，職責(zé)鏈模式：定義：使多個(gè)對(duì)象都有機(jī)會(huì)處理請(qǐng)求，從而避免請(qǐng)求的發(fā)送者和接收者之間的耦合關(guān)系。將這些對(duì)象連成一條鏈，并沿著這條鏈傳遞請(qǐng)求，直到有一個(gè)對(duì)象處理它為止。請(qǐng)求在這個(gè)鏈上傳遞，直到鏈上的某一個(gè)對(duì)象決定處理此請(qǐng)求?？蛻?hù)并不知道鏈上的哪一個(gè)對(duì)象最終處理這個(gè)請(qǐng)求，系統(tǒng)可以在不影響客戶(hù)端的情況下動(dòng)態(tài)的重新組織鏈和分配責(zé)任。一個(gè)請(qǐng)求可能有多個(gè)接受者，但是最后真正的接受者只有一個(gè)。一個(gè)請(qǐng)求可以最終不被任何接收端對(duì)象所接受。處理者有兩個(gè)選擇：承擔(dān)責(zé)任或者把責(zé)任推給下家。純的責(zé)任鏈模式 : 規(guī)定一個(gè)具體處理者角色只能對(duì)請(qǐng)求作出兩種動(dòng)作：自己處理；傳給下家。不能出現(xiàn)處理了一部分，把剩下的傳給了下家的情況。而且請(qǐng)求在責(zé)任鏈中必須被處理，而不能出現(xiàn)無(wú)果而終的結(jié)局。責(zé)任鏈的“鏈”只是為了說(shuō)明一種傳遞的思想，在實(shí)現(xiàn)的過(guò)程中實(shí)際可以直線，樹(shù)狀，環(huán)狀等。責(zé)任鏈模式優(yōu)缺點(diǎn):降低了耦合、提高了靈活性。但是責(zé)任鏈模式可能會(huì)帶來(lái)一些額外的性能損耗，因?yàn)樗看螆?zhí)行請(qǐng)求都要從鏈子開(kāi)頭開(kāi)始遍歷。責(zé)任鏈的維護(hù)：組建責(zé)任連接，這里我們自己維護(hù)。以參考使用list 或者map 來(lái)進(jìn)行注冊(cè)?？梢允褂胹pring 來(lái)管理具體處理者角色的引入。當(dāng)有了新的處理者需要添加的時(shí)候，僅僅需要修改下配置文件。應(yīng)用舉例：處理UI的消息古代：墨子.迎敵祠里描守城軍隊(duì)的結(jié)構(gòu)：“城上步一甲、一戟，其贊三人。五步有伍長(zhǎng)，十步有什長(zhǎng)，百步有佰長(zhǎng)，旁有大帥，中有大將，皆有司吏卒長(zhǎng)?！笔?、Mediator，中介者模式中介者模式又叫調(diào)停者模式。定義:用一個(gè)中介對(duì)象來(lái)封裝一系列關(guān)于對(duì)象交互行為.中介者使各個(gè)對(duì)象不需要顯示地相互引用，從而使其耦合性松散，而且可以獨(dú)立地改變他們之間的交互。用一個(gè)中介對(duì)象來(lái)封裝一系列的對(duì)象交互。中介者使各對(duì)象不需要顯式的相互引用，從而使其耦合松散，而且可以獨(dú)立地改變它們之間的交互。當(dāng)某些對(duì)象之間的作用發(fā)生改變時(shí)，不會(huì)立即影響其他的一些對(duì)象之間的作用。保證這些作用可以彼此獨(dú)立的變化。調(diào)停者模式將多對(duì)多的相互作用轉(zhuǎn)化為一對(duì)多的相互作用。調(diào)停者模式將對(duì)象的行為和協(xié)作抽象化，把對(duì)象在小尺度的行為上與其他對(duì)象的相互作用分開(kāi)處理。應(yīng)用： 在軟件構(gòu)建過(guò)程中，經(jīng)常會(huì)出現(xiàn)多個(gè)對(duì)象互相關(guān)聯(lián)交互的情況，對(duì)象之間常常會(huì)維持一種復(fù)雜的引用關(guān)系，如果遇到一些需求的更改，這種直接的引用關(guān)系將面臨不斷地變化。在這種情況下，我們可使用一個(gè)“中介對(duì)象”來(lái)管理對(duì)象間的關(guān)聯(lián)關(guān)系，避免相互交互的對(duì)象之間的緊耦合引用關(guān)系，從而更好地抵御變化。應(yīng)用舉例：聊天室程序。隨著控制邏輯的復(fù)雜化，Mediator具體對(duì)象的實(shí)現(xiàn)可能相當(dāng)復(fù)雜。這時(shí)候可以對(duì)Mediator對(duì)象進(jìn)行分解處理。十四、Visitor，訪問(wèn)者模式：定義：作用于某個(gè)對(duì)象群中各個(gè)對(duì)象的操作. 它可以使你在不改變這些對(duì)象本身的情況下,定義作用于這些對(duì)象的新操作.簡(jiǎn)單的說(shuō)，就是對(duì)象不變，作用于對(duì)象的操作變化時(shí)，可采用該模式。使用Visitor模式的前提：使用訪問(wèn)者模式是對(duì)象群結(jié)構(gòu)中(Collection) 中的對(duì)象類(lèi)型很少改變。在兩個(gè)接口Visitor（訪問(wèn)者）和Visitable（可訪者）中,確保Visitable很少變化,也就是說(shuō)，確保不能老有新的Element元素類(lèi)型加進(jìn)來(lái)，可以變化的是訪問(wèn)者行為或操作,當(dāng)需要添加新的操作的時(shí)候，只需要添加一個(gè)Visitor實(shí)現(xiàn)類(lèi)即可。這種結(jié)構(gòu)把擴(kuò)展操作所帶來(lái)的改變轉(zhuǎn)嫁給了Visitor的子類(lèi)。不但Visitor實(shí)現(xiàn)要變化，Visistable也要增加相應(yīng)行為，GOF建議是,不如在這些對(duì)象類(lèi)中直接逐個(gè)定義操作，無(wú)需使用訪問(wèn)者設(shè)計(jì)模式（但在java中，可結(jié)合使用java的反射機(jī)制解決這種情況）。應(yīng)用舉例：各大互聯(lián)網(wǎng)服務(wù)商 提出的所謂的應(yīng)用開(kāi)放平臺(tái)，跟這種思路相似。十五、Interpreter，解釋器模式：定義：給定一個(gè)語(yǔ)言，定義它的文法的一種表示，并提供一個(gè)解釋器，來(lái)解釋該語(yǔ)言中的句子。給定一個(gè)語(yǔ)言后，可以定義出其文法的一種表示，并同時(shí)提供一個(gè)解釋器?？蛻?hù)端可以使用這個(gè)解釋器來(lái)解釋這個(gè)語(yǔ)言中的句子。解釋器模式將描述怎樣在有了一個(gè)簡(jiǎn)單的文法后，使用模式設(shè)計(jì)解釋這些語(yǔ)句。在解釋器模式里面提到的語(yǔ)言是指任何解釋器對(duì)象能夠解釋的任何組合。在解釋器模式中需要定義一個(gè)代表文法的命令類(lèi)的等級(jí)結(jié)構(gòu)，也就是一系列的組合規(guī)則。每一個(gè)命令對(duì)象都有一個(gè)解釋方法，代表對(duì)命令對(duì)象的解釋。命令對(duì)象的等級(jí)結(jié)構(gòu)中的對(duì)象的任何排列組合都是一個(gè)語(yǔ)言。應(yīng)用舉例：把阿拉伯?dāng)?shù)字變成中文數(shù)字，把日期變成農(nóng)歷的日期，Quartz表達(dá)式的解釋?zhuān)齽t表達(dá)式，sql語(yǔ)句等。氣象局?jǐn)?shù)據(jù)判斷分析項(xiàng)目：用到數(shù)據(jù)過(guò)濾器。(T 50000 : 60000 or T 70000 : 80000 or T 90000 : 95000 or T 100000 : 180000)。 十六、Memento，備忘錄模式：定義：在不破壞封裝性的前提下，捕獲一個(gè)對(duì)象的內(nèi)部狀態(tài)，并在該對(duì)象之外保存這個(gè)狀態(tài)。這樣以后就可將該對(duì)象恢復(fù)到原先保存的狀態(tài)。備忘錄對(duì)象（Memento對(duì)象）是一個(gè)用來(lái)存儲(chǔ)另外一個(gè)對(duì)象內(nèi)部狀態(tài)的快照的對(duì)象。缺點(diǎn)：Memento模式的缺點(diǎn)是耗費(fèi)大,如果內(nèi)部狀態(tài)很多,再保存一份,無(wú)意要浪費(fèi)大量?jī)?nèi)存.應(yīng)用舉例：JSP+JavaBean 開(kāi)發(fā)中，表單信息的記錄。1.3. 結(jié)構(gòu)型結(jié)構(gòu)型：處理類(lèi)與對(duì)象間的組合。十七、Composite，組合模式：組合模式又叫合成模式。定義：將對(duì)象以樹(shù)形結(jié)構(gòu)組織起來(lái),以達(dá)成“部分整體” 的層次結(jié)構(gòu)，使得客戶(hù)端對(duì)單個(gè)對(duì)象和組合對(duì)象的使用具有一致性.l 合成模式將對(duì)象組織到樹(shù)結(jié)構(gòu)中，可以用來(lái)描述整體與部分的關(guān)系。l Composite使得用戶(hù)對(duì)單個(gè)對(duì)象和組合對(duì)象的使用具有一致性。l 合成模式就是一個(gè)處理對(duì)象的樹(shù)結(jié)構(gòu)的模式。l 合成模式使得客戶(hù)端把一個(gè)個(gè)單獨(dú)的成分對(duì)象和由他們復(fù)合而成的合成對(duì)象同等看待?？聪陆M合模式的組成。1) 抽象構(gòu)件角色(Component)：它為組合中的對(duì)象聲明接口，也可以為共有接口實(shí)現(xiàn)缺省行為。2) 樹(shù)葉構(gòu)件角色(Leaf)：在組合中表示葉節(jié)點(diǎn)對(duì)象沒(méi)有子節(jié)點(diǎn)，實(shí)現(xiàn)抽象構(gòu)件角色聲明的接口。3) 樹(shù)枝構(gòu)件角色(Composite)：在組合中表示分支節(jié)點(diǎn)對(duì)象有子節(jié)點(diǎn)，實(shí)現(xiàn)抽象構(gòu)件角色聲明的接口；存儲(chǔ)子部件。組合模式中必須提供對(duì)子對(duì)象的管理方法，不然無(wú)法完成對(duì)子對(duì)象的添加刪除等操作。但是管理方法是在Component 中就聲明還是在Composite中聲明呢？一種方式是在Component 里面聲明所有的用來(lái)管理子類(lèi)對(duì)象的方法，以達(dá)到Component 接口的最大化。目的就是為了使客戶(hù)看來(lái)在接口層次上樹(shù)葉和分支沒(méi)有區(qū)別透明性。但樹(shù)葉是不存在子類(lèi)的，因此Component 聲明的一些方法對(duì)于樹(shù)葉來(lái)說(shuō)是不適用的。這樣也就帶來(lái)了一些安全性問(wèn)題。另一種方式就是只在Composite 里面聲明所有的用來(lái)管理子類(lèi)對(duì)象的方法。這樣就避免了上一種方式的安全性問(wèn)題，但是由于葉子和分支有不同的接口，所以又失去了透明性。設(shè)計(jì)模式一書(shū)認(rèn)為：在這一模式中，相對(duì)于安全性，我們比較強(qiáng)調(diào)透明性。對(duì)于第一種方式中葉子節(jié)點(diǎn)內(nèi)不需要的方法可以使用空處理或者異常報(bào)告的方式來(lái)解決。十八、Facade，外觀模式：外觀模式又叫門(mén)面模式。定義: 為子系統(tǒng)中的一組接口提供一個(gè)一致的界面，F(xiàn)acade模式定義了一個(gè)高層接口，這個(gè)接口使得這一子系統(tǒng)更加容易使用。直接訪問(wèn)模式。外觀模式外觀模式減少了客戶(hù)程序和子系統(tǒng)之間的耦合，增加了可維護(hù)性.外觀模式有3個(gè)角色（門(mén)面角色，子系統(tǒng)角色，客戶(hù)端角色）。1) 門(mén)面角色（facade）：這是門(mén)面模式的核心。它被客戶(hù)角色調(diào)用，因此它熟悉子系統(tǒng)的功能。它內(nèi)部根據(jù)客戶(hù)角色已有的需求預(yù)定了幾種功能組合。2) 子系統(tǒng)角色：實(shí)現(xiàn)了子系統(tǒng)的功能。對(duì)它而言，facade角色就和客戶(hù)角色一樣是未知的，它沒(méi)有任何facade角色的信息和鏈接。3) 客戶(hù)角色：調(diào)用facade角色來(lái)完成要得到的功能。外部與一個(gè)子系統(tǒng)的通信必須通過(guò)一個(gè)統(tǒng)一的門(mén)面對(duì)象進(jìn)行。門(mén)面模式提供一個(gè)高層次的接口，使得子系統(tǒng)更易于使用。每一個(gè)子系統(tǒng)只有一個(gè)門(mén)面類(lèi)，而且此門(mén)面類(lèi)只有一個(gè)實(shí)例，也就是說(shuō)它是一個(gè)單例模式。但整個(gè)系統(tǒng)可以有多個(gè)門(mén)面類(lèi)。要點(diǎn)：1 外觀模式為復(fù)雜子系統(tǒng)提供了一個(gè)簡(jiǎn)單接口，并不為子系統(tǒng)添加新的功能和行為。2 外觀模式實(shí)現(xiàn)了子系統(tǒng)與客戶(hù)之間的松耦合關(guān)系。3 外觀模式?jīng)]有封裝子系統(tǒng)的類(lèi)，只是提供了簡(jiǎn)單的接口。如果應(yīng)用需要，它并不限制客戶(hù)使用子系統(tǒng)類(lèi)。因此可以在系統(tǒng)易用性與通用性之間選擇。4 外觀模式注重的是簡(jiǎn)化接口，它更多的時(shí)候是從架構(gòu)的層次去看整個(gè)系統(tǒng)，而并非單個(gè)類(lèi)的層次。5 外觀模式經(jīng)常使用單例實(shí)現(xiàn)，但子系統(tǒng)們可以有多個(gè)Faade。使用時(shí)的注意項(xiàng)：2. 子系統(tǒng)可以由Faade調(diào)用，也可以由Client直接調(diào)用。3. 子系統(tǒng)不知道Faade的存在，對(duì)于子系統(tǒng)，F(xiàn)aade只是一個(gè)Client。 協(xié)作：1. 客戶(hù)程序通過(guò)發(fā)送請(qǐng)求給Faade的方式與子系統(tǒng)通訊，F(xiàn)aade將這些消息轉(zhuǎn)發(fā)給適當(dāng)?shù)淖酉到y(tǒng)對(duì)象。2. 使用Faade的客戶(hù)程序不需要直接訪問(wèn)子系統(tǒng)對(duì)象。適用性：1. 為一個(gè)復(fù)雜子系統(tǒng)提供一個(gè)簡(jiǎn)單接口。2. 減少子系統(tǒng)之間以及子系統(tǒng)與客戶(hù)端的依賴(lài)性，提高子系統(tǒng)的獨(dú)立性和可移植性。3. 在層次化結(jié)構(gòu)中，可以使用Facade模式定義系統(tǒng)中每一層的入口。簡(jiǎn)化各層之間的依賴(lài)。十九、Proxy，代理模式： 定義：為其他對(duì)象提供一種代理以控制對(duì)這個(gè)對(duì)象的訪問(wèn)。某些情況下，客戶(hù)不想或者不能夠直接引用一個(gè)對(duì)象，代理對(duì)象可以在客戶(hù)和目標(biāo)對(duì)象直接起到中介的作用?？蛻?hù)端分辨不出代理主題對(duì)象與真實(shí)主題對(duì)象。代理模式可以并不知道真正的被代理對(duì)象，而僅僅持有一個(gè)被代理對(duì)象的接口，這時(shí)候代理對(duì)象不能夠創(chuàng)建被代理對(duì)象，被代理對(duì)象必須有系統(tǒng)的其他角色代為創(chuàng)建并傳入。1) 抽象主題角色：聲明了真實(shí)主題和代理主題的共同接口。2) 代理主題角色：內(nèi)部包含對(duì)真實(shí)主題的引用，并且提供和真實(shí)主題角色相同的接口。3) 真實(shí)主題角色：定義真實(shí)的對(duì)象。Proxy模式的幾個(gè)要點(diǎn)“增加一層間接層”是軟件系統(tǒng)中對(duì)許多復(fù)雜問(wèn)題的一種常見(jiàn)解決方法。在面向?qū)ο笙到y(tǒng)中，直接使用某些對(duì)象會(huì)來(lái)帶很多問(wèn)題，作為間接層的Proxy對(duì)象便是解決這一問(wèn)題的常用手段。具體Proxy設(shè)計(jì)模式的實(shí)現(xiàn)方法、實(shí)現(xiàn)粒度都相差很大，有些可能對(duì)單個(gè)對(duì)象做細(xì)粒度的控制，有些可能對(duì)組件模塊提供抽象代理層，在架構(gòu)層次對(duì)對(duì)象做Proxy。Proxy并不一定要求保持接口的一致性，只要能夠?qū)崿F(xiàn)間接控制，有時(shí)候損及一些透明性是可以接受的。總結(jié)：代理模式能夠協(xié)調(diào)調(diào)用者和被調(diào)用者，能夠在一定程度上降低系統(tǒng)的耦合度。代理模式中的真實(shí)主題角色可以結(jié)合組合模式來(lái)構(gòu)造，這樣一個(gè)代理主題角色就可以對(duì)一系列的真實(shí)主題角色有效，提高代碼利用率，減少不必要子類(lèi)的產(chǎn)生。舉例：現(xiàn)在流行的分布計(jì)算方式RMI等都是Proxy模式的應(yīng)用.。二十、Adapter,適配器模式：定義：將一個(gè)類(lèi)的接口轉(zhuǎn)換成客戶(hù)希望的另一個(gè)接口。從而使得原本由于接口不兼容而不能一起工作的那些類(lèi)可以一起工作。適配類(lèi)可以根據(jù)參數(shù)返還一個(gè)合適的實(shí)例給客戶(hù)端。舉例：java 的Swing編程中常用。二十一、Decrator，裝飾模式：裝飾模式（Decorator）也叫包裝器模式（Wrapper）定義：動(dòng)態(tài)地給一個(gè)對(duì)象增加一些額外的職責(zé)。就增加的功能來(lái)說(shuō)，Decorator模式相比生成子類(lèi)更加靈活。裝飾模式的組成。1) 抽象構(gòu)件角色（Component）：定義一個(gè)抽象接口，以規(guī)范準(zhǔn)備接收附加責(zé)任的對(duì)象。2) 具體構(gòu)件角色(Concrete Component)：這是被裝飾者，定義一個(gè)將要被裝飾增加功能的類(lèi)。3) 裝飾角色(Decorator)：持有一個(gè)構(gòu)件對(duì)象的實(shí)例，并定義了抽象構(gòu)件定義的接口。4) 具體裝飾角色(Concrete Decorator)：負(fù)責(zé)給構(gòu)件添加增加的功能。裝飾模式以對(duì)客戶(hù)端透明的方式擴(kuò)展對(duì)象的功能，是繼承關(guān)系的一個(gè)替代方案，提供比繼承更多的靈活性。動(dòng)態(tài)給一個(gè)對(duì)象增加功能，這些功能可以再動(dòng)態(tài)的撤消。增加由一些基本功能的排列組合而產(chǎn)生的非常大量的功能。適用性：以下情況使用Decorator模式1. 需要擴(kuò)展一個(gè)類(lèi)的功能，或給一個(gè)類(lèi)添加附加職責(zé)。2. 需要?jiǎng)討B(tài)的給一個(gè)對(duì)象添加功能，這些功能可以再動(dòng)態(tài)的撤銷(xiāo)。3. 需要增加由一些基本功能的排列組合而產(chǎn)生的非常大量的功能，從而使繼承關(guān)系變的不現(xiàn)實(shí)。4. 當(dāng)不能采用生成子類(lèi)的方法進(jìn)行擴(kuò)充時(shí)。一種情況是，可能有大量獨(dú)立的擴(kuò)展，為支持每一種組合將產(chǎn)生大量的子類(lèi)，使得子類(lèi)數(shù)目呈爆炸性增長(zhǎng)。另一種情況可能是因?yàn)轭?lèi)定義被隱藏，或類(lèi)定義不能用于生成子類(lèi)。 優(yōu)點(diǎn)：1. Decorator模式與繼承關(guān)系的目的都是要擴(kuò)展對(duì)象的功能，但是Decorator可以提供比繼承更多的靈活性。2. 通過(guò)使用不同的具體裝飾類(lèi)以及這些裝飾類(lèi)的排列組合，設(shè)計(jì)師可以創(chuàng)造出很多不同行為的組合。缺點(diǎn)：1. 這種比繼承更加靈活機(jī)動(dòng)的特性，也同時(shí)意味著更加多的復(fù)雜性。2. 裝飾模式會(huì)導(dǎo)致設(shè)計(jì)中出現(xiàn)許多小類(lèi)，如果過(guò)度使用，會(huì)使程序變得很復(fù)雜。3. 裝飾模式是針對(duì)抽象組件（Component）類(lèi)型編程。但是，如果你要針對(duì)具體組件編程時(shí)，就應(yīng)該重新思考你的應(yīng)用架構(gòu)，以及裝飾者是否合適。當(dāng)然也可以改變Component接口，增加新的公開(kāi)的行為，實(shí)現(xiàn)“半透明”的裝飾者模式。在實(shí)際項(xiàng)目中要做出最佳選擇。應(yīng)用舉例：java的I/O實(shí)現(xiàn)。二十二、Bridge，橋模式：定義：將抽象和行為劃分開(kāi)來(lái),使他們可以獨(dú)立的變化,但能動(dòng)態(tài)的結(jié)合。在面向?qū)ο笤O(shè)計(jì)的基本概念中，對(duì)象這個(gè)概念實(shí)際是由屬性和行為兩個(gè)部分組成的，屬性我們可以認(rèn)為是一種靜止的，是一種抽象，一般情況下，行為是包含在一個(gè)對(duì)象中，但是，在有的情況下，我們需要將這些行為也進(jìn)行歸類(lèi)，形成一個(gè)總的行為接口，這就是橋模式的用處。如果不希望抽象部分和行為有一種固定的綁定關(guān)系，而是應(yīng)該可以動(dòng)態(tài)聯(lián)系的。我們就可以考慮橋模式。將抽象化與實(shí)現(xiàn)化脫耦，使得二者可以獨(dú)立的變化，也就是說(shuō)將他們之間的強(qiáng)關(guān)聯(lián)變成弱關(guān)聯(lián)，也就是指在一個(gè)軟件系統(tǒng)的抽象化和實(shí)現(xiàn)化之間使用組合/聚合關(guān)系而不是繼承關(guān)系，從而使兩者可以獨(dú)立的變化（“組合優(yōu)先于繼承”的思想）。應(yīng)用舉例：數(shù)據(jù)庫(kù)訪問(wèn)的DAO模式。二十三、Flyweight，享元模式定義：運(yùn)用共享技術(shù)有效地支持大量細(xì)粒度的對(duì)象。避免大量擁有相同內(nèi)容的小類(lèi)的開(kāi)銷(xiāo)(如耗費(fèi)內(nèi)存),使大家共享一個(gè)類(lèi)(元類(lèi)).享元模式的特點(diǎn)是，復(fù)用我們內(nèi)存中已存在的對(duì)象，降低系統(tǒng)創(chuàng)建對(duì)象實(shí)例的性能消耗，類(lèi)似于緩存的思想。享元模式以共享的方式高效的支持大量的細(xì)粒度對(duì)象。享元模式能做到共享的關(guān)鍵是區(qū)分“內(nèi)蘊(yùn)狀態(tài)”和“外蘊(yùn)狀態(tài)”。內(nèi)蘊(yùn)狀態(tài)存儲(chǔ)在享元內(nèi)部，不會(huì)隨環(huán)境的改變而有所不同。外蘊(yùn)狀態(tài)是隨環(huán)境的改變而改變的。外蘊(yùn)狀態(tài)不能影響內(nèi)蘊(yùn)狀態(tài)，它們是相互獨(dú)立的。將可以共享的狀態(tài)和不可以共享的狀態(tài)從常規(guī)類(lèi)中區(qū)分開(kāi)來(lái)，將不可以共享的狀態(tài)從類(lèi)里剔除出去?？蛻?hù)端不可以直接創(chuàng)建被共享的對(duì)象，而應(yīng)當(dāng)使用一個(gè)工廠對(duì)象負(fù)責(zé)創(chuàng)建被共享的對(duì)象。享元模式大幅度的降低內(nèi)存中對(duì)象的數(shù)量。抽象享元角色(Flyweight類(lèi))：此角色是所有的具體享元類(lèi)的超類(lèi)，為這些類(lèi)規(guī)定出需要實(shí)現(xiàn)的公共接口。那些需要外蘊(yùn)狀態(tài)的操作可以通過(guò)調(diào)用商業(yè)方法以參數(shù)形式傳入。 具體享元(ConcreteFlyweight)角色：實(shí)現(xiàn)抽象享元角色所規(guī)定的接口。如果有內(nèi)蘊(yùn)狀態(tài)的話，必須負(fù)責(zé)為內(nèi)蘊(yùn)狀態(tài)提供存儲(chǔ)空間。享元對(duì)象的內(nèi)蘊(yùn)狀態(tài)必須與對(duì)象所處的周?chē)h(huán)境無(wú)關(guān)，從而使得享元對(duì)象可以在系統(tǒng)內(nèi)共享的。享元工廠(FlyweightFactory) 角色：本角色負(fù)責(zé)創(chuàng)建和管理享元角色。本角色必須保證享元對(duì)象可以被系統(tǒng)適當(dāng)?shù)毓蚕?。?dāng)一個(gè)客戶(hù)端對(duì)象調(diào)用一個(gè)享元對(duì)象的時(shí)候，享元工廠角色會(huì)檢查系統(tǒng)中是否已經(jīng)有一個(gè)復(fù)合要求的享元對(duì)象。如果已經(jīng)有了，享元工廠角色就應(yīng)當(dāng)提供這個(gè)已經(jīng)有的享元對(duì)象；如果系統(tǒng)中沒(méi)有一個(gè)適當(dāng)?shù)南碓獙?duì)象的話，享元工廠角色就應(yīng)當(dāng)創(chuàng)建一個(gè)合適的享元對(duì)象?？蛻?hù)端(Client)角色：本角色需要維護(hù)一個(gè)對(duì)所有享元對(duì)象的引用。本角色需要自行存儲(chǔ)所有享元對(duì)象的外蘊(yùn)狀態(tài)Flyweight模式的幾個(gè)要點(diǎn)面向?qū)ο蠛芎玫亟鉀Q了抽象性的問(wèn)題，但是作為一個(gè)運(yùn)行在機(jī)器中的程序?qū)嶓w，我們需要考慮對(duì)象的代價(jià)問(wèn)題。Flyweight設(shè)計(jì)模式主要解決面向?qū)ο蟮拇鷥r(jià)問(wèn)題，一般不觸及面向?qū)ο蟮某橄笮詥?wèn)題。Flyweight采用對(duì)象共享的做法來(lái)降低系統(tǒng)中對(duì)象的個(gè)數(shù)，從而降低細(xì)粒度對(duì)象給系統(tǒng)帶來(lái)的內(nèi)存壓力。在具體實(shí)現(xiàn)方面，要注意對(duì)象狀態(tài)的處理。享元模式的優(yōu)點(diǎn)：它大幅度地降低內(nèi)存中對(duì)象的數(shù)量。但是，它做到這一點(diǎn)所付出的代價(jià)也是很高的， 享元模式使得系統(tǒng)更加復(fù)雜，為了使對(duì)象可以共享，需要將一些狀態(tài)外部化，這使得程序的邏輯復(fù)雜化。 享元模式將享元享元對(duì)象的狀態(tài)外部化，而讀取外部狀態(tài)使得運(yùn)行時(shí)間稍微變長(zhǎng)。缺點(diǎn)：它使得系統(tǒng)邏輯復(fù)雜化，而且在一定程度上外蘊(yùn)狀態(tài)影響了系統(tǒng)的速度。1.4. 設(shè)計(jì)模式的總結(jié)1.4.1各設(shè)計(jì)模式的總結(jié)。創(chuàng)建型模式Singleton模式解決的是實(shí)體對(duì)象個(gè)數(shù)的問(wèn)題。除了Singleton之外，其他創(chuàng)建型模式解決的都是new所帶來(lái)的耦合關(guān)系。Factory Method，Abstract Factory，Builder都需要一個(gè)額外的工廠類(lèi)來(lái)負(fù)責(zé)實(shí)例化“易變對(duì)象”，而Prototype則是通過(guò)原型（一個(gè)特殊的工廠類(lèi)）來(lái)克隆“易變對(duì)象”。如果遇到“易變類(lèi)”，起初的設(shè)計(jì)通常從Factory Method開(kāi)始，當(dāng)遇到更多的復(fù)雜變化時(shí)，再考慮重構(gòu)為其他三種工廠模式（Abstract Factory，Builder，Prototype）。結(jié)構(gòu)型模式Adapter模式注重轉(zhuǎn)換接口，將不吻合的接口適配對(duì)接（適合于舊系統(tǒng)）Bridge模式注重分離接口與其實(shí)現(xiàn)，支持多維度變化Composite模式注重統(tǒng)一接口，將“一對(duì)多”的關(guān)系轉(zhuǎn)化為“一對(duì)一”的關(guān)系Decorator模式注重穩(wěn)定接口，在此前提下為對(duì)象擴(kuò)展功能Facade模式注重簡(jiǎn)化接口，簡(jiǎn)化組件系統(tǒng)與外部客戶(hù)程序的依賴(lài)關(guān)系Flyweight模式注重保留接口，在內(nèi)部使用共享技術(shù)對(duì)對(duì)象存儲(chǔ)進(jìn)行優(yōu)化，F(xiàn)lyweight 設(shè)計(jì)模式主要解決面向?qū)ο蟮拇鷥r(jià)問(wèn)題Proxy模式注重假借接口，增加間接層來(lái)實(shí)現(xiàn)靈活控制行為型模式Template Method模式封裝算法結(jié)構(gòu)，支持算法子步驟變化Strategy模式注重封裝算法，支持算法的變化State模式注重封裝與狀態(tài)相關(guān)的行為，支持狀態(tài)的變化Memento模式注重封裝對(duì)象狀態(tài)變化，支持狀態(tài)保存/恢復(fù)Mediator模式注重封裝對(duì)象間的交互，支持對(duì)象交互的變化Chain Of Responsibility模式注重封裝對(duì)象責(zé)任，支持責(zé)任的變化Command模式注重將請(qǐng)求封裝為對(duì)象，支持請(qǐng)求的變化Iterator模式注重封裝集合對(duì)象內(nèi)部結(jié)構(gòu)，支持集合的變化Interpreter模式注重封裝特定領(lǐng)域變化，支持領(lǐng)域問(wèn)題的頻繁變化Observer模式注重封裝對(duì)象通知，支持通信對(duì)象的變化Visitor模式注重封裝對(duì)象操作變化，支持在運(yùn)行時(shí)為類(lèi)層次結(jié)構(gòu)動(dòng)態(tài)添加新的操作1.4.2模式之間的關(guān)系圖1.4.3設(shè)計(jì)模式應(yīng)用結(jié)束語(yǔ)l 設(shè)計(jì)模式建立在對(duì)系統(tǒng)變化點(diǎn)的基礎(chǔ)上進(jìn)行，哪里有變化點(diǎn)，哪里應(yīng)用設(shè)計(jì)模式。l 設(shè)計(jì)模式應(yīng)該以演化的方式來(lái)獲得，系統(tǒng)的變化點(diǎn)往往是經(jīng)過(guò)不斷演化才能準(zhǔn)確定位。l 不能為了模式而模式，設(shè)計(jì)模式是一種軟件設(shè)計(jì)的軟力量，而非規(guī)范標(biāo)準(zhǔn)。不應(yīng)夸大設(shè)計(jì)模式的作用。l 不要刻意的去使自己的代碼來(lái)符合一個(gè)模式的公式。只要能