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