1.簡單工廠模式

用一個單獨的類來創造例項。

2. 策略模式（Strategy）

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

 主要用於：需要在不同時間應用不同的業務規則，就可以考慮用策略模式處理這種變化的可能性。

3.單一職責原則（SRP）:就一個類而言，應該僅有一個引起它變化的原因。

   若一個類承擔的職責過多，就等於把這些職責耦合在一起，一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這

種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。

4.開放-封閉原則或叫開-閉原則（OCP, The Open-Closed Principle）

5.依賴倒轉原則或依賴倒置原則：抽象不依賴細節，細節應該依賴於抽象，即要針對介面程式設計，不要對實現程式設計。

   a.高層模組不應該依賴底層模組。兩個都應該依賴抽象。

   b.抽象不依賴細節，細節應該依賴於抽象

里氏代換原則（LSP）:子型別必須能夠替換掉它們的父型別。

 一個軟體實體若使用的是一個父類，那麼一定適用於其子類，而且它察覺不出父類物件與子類物件的區別。即，

在軟體裡面，把父類都替換成它的子類，程式的行為沒有變化。

6.裝飾模式

動態地給一個物件新增一些額外的職責，就增加功能來說，裝飾模式比生成子類更靈活。

每個裝飾物件的實現和使用這個物件分開了，每個裝飾物件只關心自己的功能，不需關心如何被新增到物件鏈當中。

好處：有效地把類的核心職責和裝飾功能區分開，簡化了原有的類，且可以去除相關類中重複的裝飾模式。

7.代理模式

為其他物件提供一種代理以控制對這個物件的訪問。

8.工廠方法模式（Factory Method）

定義一個用於建立物件的介面，讓子類決定例項化哪一個類。工廠方法使一個類的例項化延遲到其子類。

簡單工廠模式最大優點在於工廠類中包含了必要的邏輯判斷，根據客戶端的選擇條件動態例項化相關的類，對於客戶端來說，去除了與具體產品的依賴，但需在工廠類中新增case選擇，違背了開放-封閉原則。

工廠方法模式實現時，客戶端需決定例項化哪一個工廠來實現運算類，選擇判斷的問題還是存在的，即工廠方法把簡單工廠的內部邏輯判斷轉移到了客戶端程式碼來進行。你想要加功能，本來是改工廠類的（簡單工廠模式），現在是修改客戶端（工廠方法模式）。

9.原型模式（Prototype）:用原型例項指定建立物件的種類，並且通過拷貝這些原型建立新的物件。

即是從一個物件再建立另外一個可定製的物件，而且不需知道任何建立的細節。

淺複製：被複制物件的所有變數都含有與原來的物件相同的值，而所有的對其他物件的引用都仍然指向原來的物件。

深複製：把引用物件的變數指向複製過的新物件，而不是原有的被引用的物件。

10.模版模式

定義一個操作中的演算法骨架，而將一些步驟延遲到子類中。模版方法使得子類可以不改變一個演算法的結構即可重定義該演算法的某些特定步驟。提供了一個很好的程式碼複用平臺，通過把不變行為搬移到超類，去除子類中的重複程式碼。

當我們要完成在某一細節層次一致的一個過程或一系列步驟，但其個別步驟在更詳細的層次上的實現可能不同時，我們通常考慮用模版方法模式來處理。

11.迪米特法則（LoD）,最少知識原則

若兩個類不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用。若其中一個類需要呼叫另一個類的某一個方法的話，可以通過第三者轉發這個呼叫。在類的結構設計上，每一個類都應當儘量降低成員的訪問許可權，強調的是類之間的鬆耦合，有利於複用，一個處在弱耦合的類被修改，不會對有關係的類造成波及。

12.外觀模式（Facade）

為子系統中的一組介面提供一個一致的介面，此模式定義了一個高層介面，這個介面使得這一子系統更加容易使用。

a.設計初期階段，層與層之間建立外觀模式

b.開發階段，子系統越來越複雜，增加外觀模式提供一個簡單介面，減少它們之間的依賴。

c.維護一個遺留的大系統，為新系統開發一個外觀Facade類，來提供設計粗糙或高度複雜的遺留程式碼的比較清晰簡單的介面，讓新系統與Facade物件互動，Facade與遺留程式碼互動所有複雜的工作。

13.建造者模式（Builder）或生成器模式

將一個複雜物件的構建與它的表示分離，使得同樣的構建過程可以建立不同的表示。

建造者模式是在當建立複雜物件的演算法應該獨立於該物件的組成部分以及它們的裝配方式時適用的模式。它主要用於建立一些複雜的物件，這些物件內部構建間的建造順序通常是穩定的，但物件內部的構建通常面臨著複雜的變化。使得構造程式碼與表示程式碼分離，由於建造者隱藏了該產品是如何組裝的，所以若需要改變一個產品的內部表示，只需要再定義一個具體的建造者就可以了。

14. 觀察者模式又叫釋出-訂閱模式（Publish/Subscribe）

定義了一種一對多的依賴關係，讓多個觀察者物件同時監聽某一個主題物件。這個主題物件在狀態發生變化時，會通知所有觀察者物件，使他們能夠自動更新自己。

當一個物件的改變需要同時改變其他物件的時候，而且它不知道具體有多少物件有待改變時，應該考慮使用觀察者模式。其本質就是在解除耦合。讓耦合的雙方都依賴於抽象，而不是依賴於具體。從而使得各自的變化不會影響到另一邊的變化。

事件委託

委託就是一種引用方法的型別。一旦為委託分配了方法，委託將與該方法具有完全相同的行為。

委託物件所搭載的所有方法必須具有相同的原型和形式，也就是擁有相同的引數列表和返回值型別。

15. 抽象工廠模式（Abstract Factory）

提供一個建立一系列相關或相互依賴物件的介面，而無需指定它們具體的類。

所有在用簡單工廠的地方，都可以考慮用反射技術來去除switch或if,解除分支判斷帶來的耦合。

16. 狀態模式（State）

當一個物件的內在狀態改變時允許改變其行為，這個物件看起來像是改變了其類。主要解決的是當控制一個物件狀態轉換的條件表示式過於複雜時的情況。把狀態的判斷邏輯轉移到表示不同狀態的一系列類當中，可以把複雜的判斷邏輯簡化。狀態模式通過把各種狀態轉移邏輯分佈到State的子類直接，來減少相互間的依賴。

當一個物件的行為取決於它的狀態，並且它必須在執行時刻根據狀態改變它的行為時，就可以考慮使用狀態模式了。

17. 介面卡模式（Adapter）

將一個類的介面轉換成客戶希望的另外一個介面。Adapter模式使得原本由於介面不相容而不能一起工作的那些類可以一起工作。

兩個類所做的事情相同或相似，但是具有不同的介面時，且雙方都不太容易修改的時候要使用它。

18.備忘錄模式（Memento）

在不破壞封裝性的前提下，捕獲一個物件的內部狀態，並在該物件之外儲存這個狀態。這樣以後就可將該物件恢復到原先儲存的狀態。

Memento模式比較適用於功能比較複雜的，但需要維護或記錄屬性歷史的類，或者需要儲存的屬性只是眾多屬性中的一部分時，Originator可以根據儲存的Memento資訊還原到前一狀態。當角色狀態改變時，可能這個狀態無效，這時候可以使用暫存起來的備忘錄將狀態復原。

19.組合模式（Composite）

將物件組合成樹形結構以表示“部分-整體”的層次結構。組合模式使得使用者對單個物件和組合物件的使用具有一致性。

需求中是體現部分與整體層次的結構時，或希望使用者可以忽略組合物件與單個物件的不同，統一地使用組合結構中的所有物件時，就可以考慮用組合模式了。

組合模式讓客戶可以一致地使用組合結構和單個物件。

20.迭代器模式（Iterator）

提供一種方法順序訪問一個聚合物件中各個元素，而又不暴露該物件的內部表示。

該模式分離了集合物件的遍歷行為，抽象出一個迭代器類來負責。

21.單例模式（Singleton）：保證一個類僅有一個例項，並提供一個訪問它的全域性訪問點。

可以嚴格地控制客戶怎樣訪問它以及何時訪問它。簡單講，就是對唯一例項的受控訪問。

雙重鎖定（Double-Check Locking）：在例項未被建立的時候加鎖處理

餓漢式單例類：在自己被載入時就將自己例項化的靜態初始化的方式（佔用系統資源）

懶漢式單例類：在第一次被引用時，才會將自己例項化。（多執行緒安全）

22.橋接模式（Bridge）：將抽象部分和它的實現部分分離，使他們都可以獨力地變化。並不是說讓抽象類與其派生類分離，因為這沒有任何意義。實現指的是抽象類和它的派生類用來實現自己的物件。通俗講，實現系統可能有多角度分類，每一種分類都有可能變化，那麼就把這種多角度分離出來讓它們獨立變化，減少它們之間的耦合。

合成/聚合複用原則（CARP）：儘量使用合成/聚合，儘量不要使用類繼承。優先使用合成/聚合，有助於保持每個類被封裝，並被集中在單個任務上。這樣類和類繼承層次會保持較小規模，並且不太可能增長為不可控制的龐然大物。

23.命令模式（Command）

將一個請求封裝為一個物件，從而使你可用不同的請求對客戶進行引數化；對請求排隊或記錄請求日誌，以及支援撤銷的操作。

a.較容易設計一個命令佇列

b.在需要情況下，可以較容易地將命令記入日誌

c.允許接收請求的一方決定是否要否決請求

d.可以容易地實現對請求的撤銷和重做。

e.由於加進新的具體命令類不影響其他的類，因此增加新的具體命令類很容易

最大優點是：命令模式把請求一個操作的物件與指導怎麼執行一個操作的物件分割開。

24.職責鏈模式（Chain of Responsibility）

使多個物件都有機會處理請求，從而避免請求的傳送者和接受者之間的耦合關係。將這個物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有有一個物件處理它為止。

職責鏈可簡化物件的相互連線，它們僅需保持一個指向其後繼者的引用，而不需要保持它所有的候選接受者的引用。

25.中介者模式（Mediator）又叫調停者模式

用一箇中介物件來封裝一系列的物件互動。中介者使各物件不需要顯式地相互引用，從而使其耦合鬆散，而且可以獨立地改變它們之間的互動。

一般應用於一組物件以定義良好但是複雜的方式進行通訊的場合，以及想定製一個分佈在多個類中的行為，而又不想生成太多的子類的場合。

26. 享元模式（Flyweight）：運用共享技術有效地支援大量細粒度的物件。

內部狀態：在享元物件內部並且不會隨環境改變而改變的共享部分

外部狀態：隨環境改變而改變的，不可以共享的狀態

享元模式可以避免大量非常相似類的開銷。若發現許多例項除了幾個引數外基本上都是相同的。若能把這些引數移到類例項的外面，在方法呼叫時將他們傳遞進來，就可以通過共享大幅度地減少單個例項的數目。

27.直譯器模式（Interpreter）

給定一個語言，定義它的文法的一種表示，並定義一個直譯器，這個直譯器使用該表示來解釋語言中的句子。正則表示式就是直譯器的一種應用。

若一種特定型別的問題發生的頻率足夠高，那麼可能就值得將該問題的各個例項表述為一個簡單語言中的句子。這樣就可以構建一個直譯器，該直譯器通過解釋這些句子來解決該問題。。使用了該模式，可以很容易改變和擴充套件文法，因為該模式使用類來表示文法規則，可以用繼承來擴充套件或改變該文法。也比較容易實現文法，因為定義抽象語法樹中各個節點的類的實現大體相似，這些類都易於直接編寫。

不足：該模式為文法中的每一條規則至少定義了一個類，因此包含許多規則的文法可能難以維護和管理。建議當文法非常複雜時，使用其他技術如語法分析程式或編譯器生成器來處理。

28.訪問者模式（Visitor）：表示一個作用於某物件結構中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用於這些元素的新操作。

適用於資料結構相對穩定的系統。目的是要把處理從資料結構分離出來。

優點：增加新的操作很容易。因為增加新的操作意味著增加一個新的訪問者。訪問者模式將有關的行為集中到一個訪問者物件中。

缺點：增加新的資料結構很難。