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