1.簡單工廠模式

2.策略模式

3.裝飾模式

4.代理模式

5.工廠方法模式

6.原型模式

7.模板方法模式

8.外觀模式

9.建造者模式

10.觀察者模式

11.抽象工廠模式

12.狀態(tài)模式

13.適配器模式

14.備忘錄模式

15.組合模式

16.迭代器模式

17.單例模式

18.橋接模式

19.命令模式

20.職責(zé)鏈模式

21.中介者模式

22.享元模式

23.解釋器模式

24.訪問者模式

一、簡單工廠模式

概念：將創(chuàng)建實例的工作與使用實例的工作分開，使用者不必關(guān)心類對象如何創(chuàng)建，實現(xiàn)了解耦。

使用方法：創(chuàng)建一個抽象產(chǎn)品類，然后創(chuàng)建具體產(chǎn)品類繼承抽象產(chǎn)品類，創(chuàng)建工廠類，在工廠類里面根據(jù)傳入的參數(shù)來實例化具體的產(chǎn)品對象。在客戶端直接生成工廠類的對象，直接調(diào)用即可。

簡單工廠模式計算器類圖

二、策略模式

1.概念：它定義了算法家族，分別封裝起來，讓它們之間可以互相替換，此模式讓算法的變化，不會影響到使用算法的客戶。

2.在Context類里面創(chuàng)建Strategy對象，然后提供一個ContextInterface()方法，在這里面直接調(diào)用AlgorithmInterface()方法。在客戶端創(chuàng)建context對象，傳入具體產(chǎn)品作為參數(shù)進(jìn)行實例化，再調(diào)用ContextInterface()即可。

策略模式類圖

三、裝飾模式

1.概念：動態(tài)地給一個對象添加一些額外的職責(zé)，就增加功能來說，裝飾模式比生成子類更為靈活。

2.Component是定義一個對象接口，可以給這些對象動態(tài)地添加職責(zé)。ConcreteComponent是定義了一個具體的對象，也可以給這個對象添加一些職責(zé)。Decorator，裝飾抽象類，繼承了Component，從外類來擴展Component類的功能，但對于Component來說，是無需知道Decorator的存在的。至于ConcreteDecorator就是具體的裝飾對象，起到給Component添加職責(zé)的功能。

3.來裝飾模式是利用SetComponent()來對對象進(jìn)行包裝的。這樣每個裝飾對象的實現(xiàn)就和如何使用這個對象分離開了，每個裝飾對象只關(guān)心自己的功能，不需要關(guān)心如何被添加到對象鏈當(dāng)中。在Decorator類里面提供了一個SetComponent()方法，在里面設(shè)置了conponent。

4.如果只有一個ConcreteComponent類 而 沒 有 抽 象 的Component類 ， 那 么 Decorator 類 可 以 是ConcreteComponent的 一 個 子 類 。 同 樣 道 理 ， 如 果 只 有 一 個ConcreteDecorator類，那么就沒有必要建立一個單獨的Decorator類，而可以把Decorator和ConcreteDecorator的責(zé)任合并成一個類。

5.裝飾模式的優(yōu)點：把類中的裝飾功能從類中搬移去除，這樣可以簡化原有的類。

裝飾模式類圖

四、代理模式

1.概念：為其他對象提供一種代理以控制對這個對象的訪問。

代理模式類圖

2.Proxy 類，保存一個引用使得代理可以訪問實體，并提供一個與Subject的接口相同的接口，這樣代理就可以用來替代實體。在客戶端直接創(chuàng)建Proxy對象的實例，然后調(diào)用Request()方法即可。

Proxy類

3.代理模式的應(yīng)用：（1）遠(yuǎn)程代理，也就是為一個對象在不同的地址空間提供局部代表。這樣可以隱藏一個對象存在于不同地址空間的事實。當(dāng)我在應(yīng)用程序的項目中加入一個Web引用，引用一個WebService，此時會在項目中生成一個WebReference的文件夾和一些文件，其實它們就是代理，這就使得客戶端程序調(diào)用代理就可以解決遠(yuǎn)程訪問的問題。

（2）虛擬代理，是根據(jù)需要創(chuàng)建開銷很大的對象。通過它來存放實例化需要很長時間的真實對象。這樣就可以達(dá)到性能的最優(yōu)化，比如說你打開一個很大的HTML網(wǎng)頁時，里面可能有很多的文字和圖片，但你還是可以很快打開它，此時你所看到的是所有的文字，但圖片卻是一張一張地下載后才能看到。那些未打開的圖片框，就是通過虛擬代理來替代了真實的圖片，此時代理存儲了真實圖片的路徑和尺寸。

（3）安全代理，用來控制真實對象訪問時的權(quán)限。一般用于對象應(yīng)該有不同的訪問權(quán)限的時候。

（4）智能指引，是指當(dāng)調(diào)用真實的對象時，代理處理另外一些事。如計算真實對象的引用次數(shù)，這樣當(dāng)該對象沒有引用時，可以自動釋放它；或當(dāng)?shù)谝淮我靡粋€持久對象時，將它裝入內(nèi)存；或在訪問一個實際對象前，檢查是否已經(jīng)鎖定它，以確保其他對象不能改變它。它們都是通過代理在訪問一個對象時附加一些內(nèi)務(wù)處理。

五、工廠方法模式

1.概念：定義一個用于創(chuàng)建對象的接口，讓子類決定實例化哪一個類。工廠方法使一個類的實例化延遲到其子類。

工廠方法類圖

2.簡單工廠模式的最大優(yōu)點在于工廠類中包含了必要的邏輯判斷，根據(jù)客戶端的選擇條件動態(tài)實例化相關(guān)的類，對于客戶端來說，去除了與具體產(chǎn)品的依賴。

3.工廠方法模式實現(xiàn)時，客戶端需要決定實例化哪一個工廠來實現(xiàn)運算類，選擇判斷的問題還是存在的，也就是說，工廠方法把簡單工廠的內(nèi)部邏輯判斷移到了客戶端代碼來進(jìn)行。你想要加功能，本來是改工廠類的，而現(xiàn)在是修改客戶端！

六、原型模式

1.概念：用原型實例指定創(chuàng)建對象的種類，并且通過拷貝這些原型創(chuàng)建新的對象。

原型模式類圖

2.原型模式其實就是從一個對象再創(chuàng)建另外一個可定制的對象，而且不需知道任何創(chuàng)建的細(xì)節(jié)。

原型類

七、模板方法模式

1.概念：定義一個操作中的算法的骨架，而將一些步驟延遲到子類中，。模板方法使得子類可以不改變一個算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟。

模板方法類圖

2.子類繼承抽象類，重寫里面的方法。在客戶端可以創(chuàng)建AbstractClass子類對象，然后調(diào)用TemplateMethod()方法。

抽象類

3.模板方法模式是通過把不變行為搬移到超類，去除子類中的重復(fù)代碼來體現(xiàn)它的優(yōu)勢。模板方法模式就是提供了一個很好的代碼復(fù)用平臺。

4.當(dāng)不變的和可變的行為在方法的子類實現(xiàn)中混合在一起的時候，不變的行為就會在子類中重復(fù)出現(xiàn)。我們通過模板方法模式把這些行為搬移到單一的地方，這樣就幫助子類擺脫重復(fù)的不變行為的糾纏?！?/h6>

八、外觀模式

1.概念：為子系統(tǒng)中的一組接口提供一個一致的界面，此模式定義了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用。

外觀模式類圖

外觀類

2.每個子系統(tǒng)類各有一種方法。在客戶端之間創(chuàng)建Facade的對象，然后調(diào)用MethodA()和Method()B方法即可。它完美地體現(xiàn)了依賴倒轉(zhuǎn)原則和迪米特法則的思想，所以是非常常用的模式之一。

九、建造者模式

1.概念：將一個復(fù)雜對象的構(gòu)建與它的表示分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。

建造者模式類圖

Product類

Builder類

ConcreteBuilder類

Director類

客戶端代碼

2.建造者模式是在當(dāng)創(chuàng)建復(fù)雜對象的算法應(yīng)該獨立于該對象的組成部分以及它們的裝配方式時適用的模式。

十、觀察者模式

1.概念：觀察者模式定義了一種一對多的依賴關(guān)系，讓多個觀察者對象同時監(jiān)聽某一個主題對象。這個主題對象在狀態(tài)發(fā)生變化時，會通知所有觀察者對象，使它們能夠自動更新自己。

觀察者模式類圖

抽象觀察者

具體觀察者

抽象被觀察者

具體被觀察者

客戶端調(diào)用

2.使用觀察者模式的時機：“當(dāng)一個對象的改變需要同時改變其他對象，而且它不知道具體有多少對象有待改變時，應(yīng)該考慮使用觀察者模式。當(dāng)一個抽象模型有兩個方面，其中一方面依賴于另一方面，這時用觀察者模式可以將這兩者封裝在獨立的對象中使它們各自獨立地改變和復(fù)用。

十一、抽象工廠模式

1.概念：提供一個創(chuàng)建一系列相關(guān)或相互依賴對象的接口，而無需指定它們具體的類。具體的例子看http://www.itdecent.cn/p/7deb64f902db

抽象工廠模式結(jié)構(gòu)圖

十二、狀態(tài)模式

1.概念：當(dāng)一個對象的內(nèi)在狀態(tài)改變時允許改變其行為，這個對象看起來像是改變了其類。

2.狀態(tài)模式主要解決的是當(dāng)控制一個對象狀態(tài)轉(zhuǎn)換的條件表達(dá)式過于復(fù)雜時的情況。把狀態(tài)的判斷邏輯轉(zhuǎn)移到表示不同狀態(tài)的一系列類當(dāng)中，可以把復(fù)雜的判斷邏輯簡化 。當(dāng)然，如果這個狀態(tài)判斷很簡單，那就沒必要用‘狀態(tài)模式’了。

狀態(tài)模式結(jié)構(gòu)圖

3.將特定的狀態(tài)相關(guān)的行為都放入一個對象中，由于所有與狀態(tài)相關(guān)的代碼都存在于某個ConcreteState中，所以通過定義新的子類可以很容易地增加新的狀態(tài)和轉(zhuǎn)換。

4.當(dāng)一個對象的行為取決于它的狀態(tài)，并且它必須在運行時刻根據(jù)狀態(tài)改變它的行為時，就可以考慮使用狀態(tài)模式了。在一個狀態(tài)里面，new下一個狀態(tài)。

十三、適配器模式

1.概念：將一個類的接口轉(zhuǎn)換成客戶希望的另外一個接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。（這里是類的適配器模式）

適配器模式結(jié)構(gòu)圖

Target類

Adaptee類

Adapter類

客戶端代碼

2.在想使用一個已經(jīng)存在的類，但如果它的接口，也就是它的方法和你的要求不相同時，就應(yīng)該考慮用適配器模式。

十四、備忘錄模式

1.概念：在不破壞封裝性的前提下，捕獲一個對象的內(nèi)部狀態(tài)，并在該對象之外保存這個狀態(tài)。這樣以后就可將該對象恢復(fù)到原先保存的狀態(tài)。

備忘錄模式結(jié)構(gòu)圖

Originator（發(fā)起人）：負(fù)責(zé)創(chuàng)建一個備忘錄Memento，用以記錄當(dāng)前時刻它的內(nèi)部狀態(tài)，并可使用備忘錄恢復(fù)內(nèi)部狀態(tài)。Originator可根據(jù)需要決定Memento存儲Originator的哪些內(nèi)部狀態(tài)。

Memento（備忘錄）：負(fù)責(zé)存儲Originator對象的內(nèi)部狀態(tài)，并可防止Originator以外的其他對象訪問備忘錄Memento。備忘錄有兩個接口，Caretaker只能看到備忘錄的窄接口，它只能將備忘錄傳遞給其他對象。Originator能夠看到一個寬接口，允許它訪問返回到先前狀態(tài)所需的所有數(shù)據(jù)。

Caretaker（管理者）：負(fù)責(zé)保存好備忘錄Memento，不能對備忘錄的內(nèi)容進(jìn)行操作或檢查。

十五、組合模式

1.概念：將對象組合成樹形結(jié)構(gòu)以表示“部分——整體”的層次結(jié)構(gòu)。組合模式使得用戶對單個對象和組合對象的使用具有一致性。

組合模式結(jié)構(gòu)圖

Compenent類

Leaf類

Composite類

客戶端代碼

2.透明方式：在Component中聲明所有用來管理子對象的方法，其中包括Add、Remove等。這樣實現(xiàn)Component接口的所有子類都具備了Add和Remove。這樣做的好處就是葉節(jié)點和枝節(jié)點對于外界沒有區(qū)別，它們具備完全一致的行為接口。但問題也很明顯，因為Leaf類本身不具備Add（）、Remove（）方法的功能，所以實現(xiàn)它是沒有意義的。

3.安全方式：在Component接口中不去聲明Add和Remove方法，那么子類的Leaf也就不需要去實現(xiàn)它，而是在Composite聲明所有用來管理子類對象的方法 ，這樣做就不會出現(xiàn)剛才提到的問題，不過由于不夠透明，所以樹葉和樹枝類將不具有相同的接口，客戶端的調(diào)用需要做相應(yīng)的判斷，帶來了不便。

4.什么時候使用組合模式：當(dāng)你發(fā)現(xiàn)需求中是體現(xiàn)部分與整體層次的結(jié)構(gòu)時 ，以及你希望用戶可以忽略組合對象與單個對象的不同，統(tǒng)一地使用組合結(jié)構(gòu)中的所有對象時，就應(yīng)該考慮用組合模式了。

十六、迭代器模式

1.概念：提供一種方法順序訪問一個聚合對象中各個元素，而又不暴露該對象的內(nèi)部表示。

2.當(dāng)你需要訪問一個聚集對象，而且不管這些對象是什么都需要遍歷的時候，你就應(yīng)該考慮用迭代器模式 。目前很少使用，因為Java已經(jīng)把這個模式做在語言中了。

迭代器模式結(jié)構(gòu)圖

十七、單例模式

1.概念：保證一個類僅有一個實例，并提供一個訪問它的全局訪問點。

單例模式結(jié)構(gòu)圖

Singleton類

2.在多線程中使用單例可能會出現(xiàn)同時訪問Singleton類的情況，這種時候我們可以給instance上鎖。

上鎖的Singleton

3.餓漢式單例類：在自己被加載時就將自己實例化。

4.懶漢式單例類：要在第一次被引用時，才會將自己實例化。

5.由于餓漢式，即靜態(tài)初始化的方式，它是類一加載就實例化的對象，所以要提前占用系統(tǒng)資源。然而懶漢式，又會面臨著多線程訪問的安全性問題，需要做雙重鎖定這樣的處理才可以保證安全。所以到底使用哪一種方式，取決于實際的需求。

十八、橋接模式

1.概念：將抽象部分與他的實現(xiàn)部分分離，使它們都可以獨立地變化。

2.什么叫抽象與它的實現(xiàn)分離，這并不是說，讓抽象類與其派生類分離，因為這沒有任何意義。實現(xiàn)指的是抽象類和它的派生類用來實現(xiàn)自己的對象。

橋接模式結(jié)構(gòu)圖

3.實現(xiàn)系統(tǒng)可能有多角度分類，每一種分類都有可能變化，那么就把這種多角度分離出來讓它們獨立變化，減少它們之間的耦合。

十九、命令模式

1.將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進(jìn)行參數(shù)化；對請求排隊或記錄請求日志，以及支持可撤銷的操作。

命令模式結(jié)構(gòu)圖

2.命令模式的優(yōu)點：第一，它能較容易地設(shè)計一個命令隊列；第二，在需要的情況下，可以較容易地將命令記入日志；第三，允許接收請求的一方?jīng)Q定是否要否決請求。第四，可以容易地實現(xiàn)對請求的撤銷和重做；第五，由于加進(jìn)新的具體命令類不影響其他的類，因此增加新的具體命令類很容易。其實還有最關(guān)鍵的優(yōu)點就是命令模式把請求一個操作的對象與知道怎么執(zhí)行一個操作的對象分割開。

二十、職責(zé)鏈模式

1.概念：使多個對象都有機會處理請求，從而避免請求的發(fā)送者和接收者之間的耦合關(guān)系。將這個對象連成一條鏈，并沿著這條鏈傳遞該請求，直到有一個對象處理它為止。

職責(zé)鏈模式結(jié)構(gòu)圖

2.這就使得接收者和發(fā)送者都沒有對方的明確信息，且鏈中的對象自己也并不知道鏈的結(jié)構(gòu)。結(jié)果是職責(zé)鏈可簡化對象的相互連接，它們僅需保持一個指向其后繼者的引用，而不需保持它所有的候選接受者的引用。

二十一、中介者模式

1.概念：用一個中介對象來封裝一系列的對象交互。中介者使各對象不需要顯示地相互引用，從而使其耦合松散，而且可以獨立地改變它們之間的交互。

中介者模式結(jié)構(gòu)圖

2.中介者模式的優(yōu)點首先是Mediator的出現(xiàn)減少了各個Colleague的耦合，使得可以獨立地改變和復(fù)用各個Colleague類和Mediator。由于把對象如何協(xié)作進(jìn)行了抽象，將中介作為一個獨立的概念并將其封裝在一個對象中，這樣關(guān)注的對象就從對象各自本身的行為轉(zhuǎn)移到它們之間的交互上來，也就是站在一個更宏觀的角度去看待系統(tǒng)。

二十二、享元模式

1.概念：運用共享技術(shù)有效地支持大量細(xì)粒度的對象。

享元模式結(jié)構(gòu)圖

Flyweight類，它是所有具體享元類的超類或接口，通過這個接口，Flyweight可以接受并作用于外部狀態(tài)。ConcreteFlyweight是繼承Flyweight超類或?qū)崿F(xiàn)Flyweight接口，并為內(nèi)部狀態(tài)增加存儲空間。UnsharedConcreteFlyweight是指那些不需要共享的Flyweight子類。因為Flyweight接口共享成為可能，但它并不強制共享。FlyweightFactory，是一個享元工廠，用來創(chuàng)建并管理Flyweight對象。它主要是用來確保合理地共享Flyweight，當(dāng)用戶請求一個Flyweight時，FlyweightFactory對象提供一個已創(chuàng)建的實例或者創(chuàng)建一個（如果不存在的話）。

2.享元模式可以避免大量非常相似類的開銷。在程序設(shè)計中，有時需要生成大量細(xì)粒度的類實例來表示數(shù)據(jù)。如果能發(fā)現(xiàn)這些實例除了幾個參數(shù)外基本上都是相同的，有時就能夠受大幅度地減少需要實例化的類的數(shù)量。如果能把那些參數(shù)移到類實例的外面，在方法調(diào)用時將它們傳遞進(jìn)來，就可以通過共享大幅度地減少單個實例的數(shù)目。

3.如果一個應(yīng)用程序使用了大量的對象，而大量的這些對象造成了很大的存儲開銷時就應(yīng)該考慮使用；還有就是對象的大多數(shù)狀態(tài)可以外部狀態(tài)，如果刪除對象的外部狀態(tài)，那么可以用相對較少的共享對象取代很多組對象，此時可以考慮使用享元模式。

二十三、解釋器模式

1.概念：給定一個語言，定義它的文法的一種表示，并定義一個解釋器，這個解釋器使用該表示來解釋語言中的句子。

2.解釋器模式需要解決的是，如果一種特定類型的問題發(fā)生的頻率足夠高，那么可能就值得將該問題的各個實例表述為一個簡單語言中的句子。這樣就可以構(gòu)建一個解釋器，該解釋器通過解釋這些句子來解決該問題。

解釋器模式結(jié)構(gòu)圖

二十四、訪問者模式

1.概念：表示一個作用于某對象結(jié)構(gòu)中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用于這些元素的新操作。

訪問者模式結(jié)構(gòu)圖

2.訪問者模式適用于數(shù)據(jù)結(jié)構(gòu)相對穩(wěn)定的系統(tǒng)。它把數(shù)據(jù)結(jié)構(gòu)和作用于結(jié)構(gòu)上的操作之間的耦合解脫開，使得操作集合可以相對自由地演化。

3.訪問者模式的目的是要把處理從數(shù)據(jù)結(jié)構(gòu)分離出來 。很多系統(tǒng)可以按照算法和數(shù)據(jù)結(jié)構(gòu)分開，如果這樣的系統(tǒng)有比較穩(wěn)定的數(shù)據(jù)結(jié)構(gòu)，又有易于變化的算法的話，使用訪問者模式就是比較合適的，因為訪問者模式使得算法操作的增加變得容易。

4.訪問者模式的優(yōu)點就是增加新的操作很容易，因為增加新的操作就意味著增加一個新的訪問者。訪問者模式將有關(guān)的行為集中到一個訪問者對象中。