一.創建型模式
1.工廠方法模式
抽象工廠角色：提供一個創建產品的接口
具體工廠角色：實現創建各類產品
與簡單工廠模式的區別是，簡單工廠是一個工廠類，沒有繼承自任何接口類。當要增加某種產品的時候，需要修改這個工廠類，不符合OCP原則。
而工廠方法模式是面向接口的，如果要增加一個產品，我們可以通過繼承接口來增加一個可以製造該產品的工廠類，而不需要修改之前的工廠類。
應用場景 創建不同種類的產品
定義創建對象的接口，封裝對象的創建過程。
具體化類的工作延遲到子類中 (實現的時候，編寫一個工廠接口，再編寫一個工廠實現，這樣具體化類的工作就延遲到工廠實現這個類裏面了)
2.抽象工廠模式
應用場景 要創建不同種類的產品，而且這些產品自身還分不同的版本
首先有個抽象工廠
抽象工廠下面有n個版本的具體工廠
每個版本的具體工廠負責創建對應版本的m個不同產品
3.單例模式
一個類只有一個instance
4.建造者模式
應用場景 產品比較複雜，需要分階段構造；不同的產品生產階段是一樣的
首先有一個包含構建階段的接口，不同的產品具體實現自己的各個構建階段(接口的實現)
然後有一個Director，將具體的產品構建過程傳給它之後，Director來負責構建流程的操作，即按照順序執行各個構建階段並返回產品
http://baike.baidu.com/link?url=6Lwn1hx74N8_zV6ae0mDEECi2KMmE2S_xriKWPB-QIW73wlIo4JCc1RiMG7W1fLZGMdznnV9uMEu-JtgRQB_rq
5.原型模式
即克隆一個對象
二.結構型模式
1.橋接模式
應用場景 當一個系統由多個方面組成，每個方面又有自己的需求變化。這種多維度的變化適用橋接模式。
比如交通系統分車子和公路兩方面，車子的類型可以變化，公路的總類也可以變化。
通過用 類的成員是另一個類的對象 這種包含組合的方式來解決這種多維度的變化
比如有個抽象車，下面有小汽車，公交車
有個抽象路，下面有城市街道路，高速路
其中抽象路里面有個成員叫車，類型是抽象車
這樣每個維度的變化只需要在自己的那個維度裏面修改而不涉及其他維度
Bridge模式是一個非常有用的模式，也非常複雜，它很好的符合了開放-封閉原則和優先使用對象，而不是繼承這兩個面向對象原則。
http://www.cnblogs.com/houleixx/archive/2008/02/23/1078877.html
另外標準敘述中的橋接模式分抽象化角色和實現化角色，抽象化角色將實現化角色當做一個成員
在上述例子中，路這個角色就是抽象化角色，車這個角色就是實現化角色
表達的意思是路的run函數實際上是調用車的run函數，具體怎麼run，是定義在具體的車的run函數裏面的
連接裏面的後面加了個人這個角色，這個時候人成了抽象化角色，路成了實現化角色
2.適配器模式
將一個類的接口封裝成適合於客戶的接口
有兩種實現：
類模式：adapter 公有繼承目標接口類，私有繼承提供者類 然後將提供者類提供的接口轉換成目標接口
對象模式: 提供者類的對象是adapter的一個成員
3.裝飾模式
應用場景 需要給某個類增加功能的時候
角色：
抽象構件
具體構件(繼承自抽象構件)
裝飾角色(繼承自抽象構件，並有一個具體構件的引用)
具體裝飾(實現新增加的那個功能)
4.組合模式
應用場景 適用於樹形結構
比如文件系統
component角色聲明文件系統結構樹中每一個節點的行爲(添加 刪除 獲取某個文件 打開文件)，即接口
left角色表示非文件夾文件，是component的一個實現,下面沒有文件或者文件夾了
composite角色表示文件系統結構樹中的每一個節點，也是component的一個實現，下面可以有n個composite作爲其兒子
5.享元模式
應用場景 大量的對象有重複的屬性，把重複的部分只保存一份，由Factory來管理這個重複的部分.客戶端自己管理每個對象不同的部分，每個對象的相同部分有Factory提供
http://fengzl.iteye.com/blog/117129
每個對象分兩個狀態
內蘊狀態->可共享部分，即上述重複的屬性
外蘊狀態->不可共享部分
抽象享元角色：所有的具體享元類的超類，規定出需要實現的公共接口。那些需要外蘊狀態的操作可以通過方法的參數傳入。抽象享元的接口使得享元變得可能，但是並不強制子類實行共享，因此並非所有的享元對象都是可以共享的。
具體享元角色：實現抽象享元角色所規定的接口。如果有內蘊狀態的話，必須負責爲內蘊狀態提供存儲空間。享元對象的內蘊狀態必須與對象所處的周圍環境無關，從而使得享元對象可以在系統內共享。複合享元角色是由具體享元角色通過複合而成。
--複合享元角色：複合享元角色所代表的對象是不可以共享的，但是可以分解成多個可以共享的具體享元角色。
享元工廠角色：負責創建和管理享元角色。本角色必須保證享元對象可以被系統適當地共享。當一個客戶端對象調用一個享元對象時，享元工廠角色會檢查系統中是否已經有一個符合要求的享元對象。如果有，享元工廠就提供這個已經有的享元對象，如果沒有，享元工廠創建一個適當的享元對象。
客戶端角色：需要維護一個對所有享元對象的引用。本角色需要自行存儲所有享元對象的外蘊狀態。
客戶端中，以內蘊狀態調用享元工廠，享元工廠查找該內蘊狀態，找到返回；沒查到將其插入共享池中再返回。客戶端得到該對象後，用外蘊狀態調用其業務方法Operation。
抽象享元包括一個operation的接口，一個表示內蘊的成員。
6.外觀模式
應用場景 將多個類的相互操作封裝起來，提供一個簡單的接口供客戶端使用
一個簡單的例子是，編譯器編譯代碼分詞法分析，語法分析，語義分析等，將這些操作封裝成編譯操作，客戶端直接調用這個編譯操作即可。
7.代理模式
(1).職責清晰真實的角色就是實現實際的業務邏輯，不用關心其他非本職責的事務，通過後期的代理完成一件完成事務，附帶的結果就是編程簡潔清晰。
(2).代理對象可以在客戶端和目標對象之間起到中介的作用，這樣起到了的作用和保護了目標對象的作用。
(3).高擴展性
代理類和委託類都實現相同的接口，客戶端請求的時候將委託類的對象傳給代理類，由代理類來執行相應方法(代理類在調用委託類的方法前後會做一些和業務邏輯不相干的事情)
三.行爲模式
1.模板模式
其意圖是定義一個操作的算法骨架，而將一些步驟延遲到子類中，可以不改變一個算法的結構即可以重新定義該算法的某些特定步驟
抽象類實現通用的算法邏輯，但是算法的具體細節由派生類提供
2.策略模式
抽象策略角色： 策略類，通常由一個接口或者抽象類實現。
具體策略角色：包裝了相關的算法和行爲。
環境角色：持有一個策略類的引用，最終給客戶端調用。
由客戶端提供具體策略，然後交給環境角色去執行策略
3.狀態模式
當一個對象的行爲取決於它的狀態，並且它必須在運行時刻根據狀態改變它的行爲時，就可以考慮使用狀態模式來。
一個操作中含有龐大的分支結構，並且這些分支決定於對象的狀態。
環境(Context)角色，也成上下文：定義客戶端所感興趣的接口，並且保留一個具體狀態類的實例。這個具體狀態類的實例給出此環境對象的現有狀態。
抽象狀態(State)角色：定義一個接口，用以封裝環境（Context）對象的一個特定的狀態所對應的行爲。
具體狀態(ConcreteState)角色：每一個具體狀態類都實現了環境（Context）的一個狀態所對應的行爲。
在狀態的行爲函數裏面，本次行爲操作完畢後，將環境角色的狀態設置爲下一狀態。
4.觀察者模式
MVC架構採用該模式，MFC,Structs採用該模式
又稱發佈訂閱模式
兩個角色
觀察者(多個，接受通知，可以改變被觀察者)
被觀察者(一個，當改變的時候發送通知)
觀察者必須向被觀察者註冊(訂閱)，所以被觀察者要維護一個觀察者列表，允許取消訂閱
5.備忘錄模式
Originator(發起人)：負責創建一個備忘錄Memento，用以記錄當前時刻自身的內部狀態，並可使用備忘錄恢復內部狀態。Originator可以根據需要決定Memento存儲自己的哪些內部狀態。
Memento(備忘錄)：負責存儲Originator對象的內部狀態，並可以防止Originator以外的其他對象訪問備忘錄。備忘錄有兩個接口：Caretaker只能看到備忘錄的窄接口，他只能將備忘錄傳遞給其他對象。Originator卻可看到備忘錄的寬接口，允許它訪問返回到先前狀態所需要的所有數據。
Caretaker(管理者):負責備忘錄Memento，不能對Memento的內容進行訪問或者操作。
6.中介者模式
設計時，同事類要向中介者類註冊，消息格式可以設計爲目標者+函數名+參數的形式
http://www.blogjava.net/jjshcc/archive/2010/09/09/331528.html
7.命令模式
抽象命令角色：提供一個命令的接口，比如開機
具體命令角色：通過調用接受者的具體方法來實現接口。比如調用電視機的開機，調用收音機的開機，調用電腦的開機
接受者角色：具體的命令執行者。比如電視，擁有具體的開機，關機，調頻方法。比如電腦開機關機(沒有調頻)
調用者角色：命令集合的封裝，比如開機，關機，調頻等
客戶端(組裝者)角色：爲不同的命令創建具體的接受者(可以不同)，將這些具體命令封裝到調用者
http://www.cnblogs.com/devinzhang/archive/2012/01/06/2315235.html
8，訪問者模式
訪問者模式把數據結構和作用於結構上的操作解耦合，使得操作集合可相對自由地演化。
訪問者模式適用於數據結構相對穩定算法又易變化的系統。因爲訪問者模式使得算法操作增加變得容易。若系統數據結構對象易於變化，經常有新的數據對象增加進來，則不適合使用訪問者模式。
訪問者模式的優點是增加操作很容易，因爲增加操作意味着增加新的訪問者。訪問者模式將有關行爲集中到一個訪問者對象中，其改變不影響系統數據結構。其缺點就是增加新的數據結構很困難。
抽象訪問者角色：提供訪問具體元素時的接口visitElementA,visitElementB...
具體訪問者角色：實現訪問具體每一個元素時的操作
抽象元素角色：提供一個統一的接口accpet(visitor *)接受訪問者的訪問
具體元素角色:實現accpet方法，當訪問者訪問時，調用訪問者中訪問自己的那個方法
對象結構角色：將元素封裝到一個元素池中，供客戶端統一調用
客戶端角色：向元素池添加具體要操作的元素，創建具體的訪問者，把訪問者傳給對象結構角色，讓它統一作用於對象池中的每一個對象
9.責任鏈模式
比如 MFC的消息傳遞機制
抽象的Handler角色：提供處理請求的接口，設置和得到後繼者的接口
具體的handler角色： 在實現處理請求的時候，判斷自己能不能處理該請求，不能的話傳給後繼者繼續處理，或者自己不能完全處理，也要傳給後繼者
10.迭代器模式
提供一種方法順序訪問一個聚合對象中各個元素，而又不需暴露該對象的內部表示
訪問一個聚合對象的內容而無需暴露它的內部表示
支持對聚合對象的多種遍歷
爲遍歷不同的聚合結構提供一個統一的接口
抽象迭代器角色：聲明begin接口，end接口，getCurrentItem接口，getNext接口
具體迭代器角色：有個類型爲聚合角色的屬性成員，通過調用這個聚合角色的一些方法來實現上述接口
抽象聚合角色：聲明迭代器需要的接口以及創建和獲取迭代器的接口。
具體聚合角色：有自己的內部數據結構，需要實現提供給迭代器的接口。有一個迭代器屬性成員。
11.解釋器模式
http://hi.baidu.com/jonw000/item/82b0d64b57e5800ce8350418
感覺就是個遞歸結構
抽象的解釋器角色：聲明一個解釋接口
終結符解釋器角色：解釋接口處理終結符
非終結符(規則)解釋器角色：按照語法規則將表達式進行拆分，遞歸解釋
上下文角色：提供一些全局的附加信息
比如表達式(a*b)/(a-b+2)
a,b,2是終結符
+ - * / 是規則，非終結符