設計模式總結:便於快速查看
前言：個人覺得設計模式就是各個對象在不同的時機、不同的調用方被創建，組合結構和封裝的側重點有些不同，從而形成了各個模式的概念。
1. 簡單工廠模式
通過在工廠類中進行判斷，然后創建需要的功能類。
優點：不必使用具體的功能類去創建該類的實例。缺點：新增一個功能類就需要在工廠類中增加一個判斷。
2. 策略模式
假設一個功能類是一個策略，調用的時候需要創建這個策略的實例，傳進一個類似策略控制中心的方法中，然后通過策略基類調用這個傳進去的實例子類的方法。
優點：就是相對工廠模式免去了創建那個功能類的判斷，簡化了工廠模式。缺點：就是把子類實例賦值給了父類，這樣就丟掉了子類新增的功能。
3. 工廠方法模式(屬於工廠模式)
把簡單工廠模式中的工廠類，做了進一步的抽象為接口或抽象類，給各個功能創建一個對應的工廠類，然后在這個工廠類里面去創建對應的實例。
缺點：當新增一個功能類，就需要創建對於的工廠類，相比簡單工廠模式，免去了判斷創建那個具體實例，但會創建過多的類，還不如策略模式。
4. 裝飾模式
一般情況下，當一個基類寫好之后，我們也許不願意去改動，也不能改動，原因是
這樣的在項目中用得比較久的基類，一旦改動，也許會影響其他功能模塊，但是，
又要在該類上面添加功能。使用繼承，當在A階段，寫出繼承類，用過一段時間，發
現又要添加新功能，於是又要從原始類或A階段的類繼承，周而復始，慢慢的，子類就越來越多，層級就越來越深。然而，事實上，在C階段需要A階段的功能，但不需要B階段的功能，在這種復雜情形下，繼承就顯得不靈活，於是想到了裝飾模式。
裝飾模式：
需要擴展一個類的功能，或給一個類增加附加責任
需要動態地給一個對象增加功能，這些功能可以再動態地撤銷。
需要增加由一些基本功能的排列組合而產生的非常大量的功能，從而使繼承關系變得不現實。
在使用裝飾模式前，需要了解虛方法和抽象方法的區別：虛方法，是實例方法，可以在子類中覆蓋，也可以由該類對象直接調用。抽象方法需要寫在抽象類中，抽象類不能實例化，所以要使用抽象方法必須由子類實現后方可調用。
該模式中，要被擴展的類可以是包含抽象方法的抽象類，也可以是包含虛方法的實例類，也可以是普通實例類。裝飾模式就是在原有基類上做擴展，至於基類是什么性質並不重要.
裝飾模式在C#代碼，和擴展方法，驚人的類似。
5. 代理模式
代理類成為實際想調用對象的中間件，可以控制對實際調用對象的訪問權限；維護實際調用對象的一個引用。
6. 原型模式
創建好了一個實例，然后用這個實例，通過克隆方式創建另一個同類型的實例，而不必關心這個新實例是如何創建的。
原型模式使用時需要注意淺拷貝與深拷貝的問題。
7. 建造者模式
每個對象都具備自己的功能，但是，它們的創建方式卻是一樣的。這個時候就需要中間這個建造者類來負責功能對象實例的創建。在調用端只需調用特定的方法即可。
這個和策略模式有點類似。
8. 抽象工廠模式
使用該功能類的功能類，利用抽象工廠去創建該功能類的實例。這樣的好處在於盡可能的避免去創建功能的實例。
更牛逼的做法就是使用反射去創建這個功能類的實例，在調用端就一點都不需要知道要去實例化那個具體的功能類。這當然不是抽象工廠模式獨有的。
9. 外觀模式
外觀模式：為外界調用提供一個統一的接口，把其他類中需要用到的方法提取出來，由外觀類進行調用。然后在調用段實例化外觀類，以間接調用需要的方法。這種方式形式上和代理模式有異曲同工之妙。
10.模板模式
模板模式：其實就是抽象出各個具體操作類的公共操作方法，在子類重新實現,然后使用子類去實例化父類。這個模板類其實可以使用接口替換。事實上接口才是專門用來定義操作規范。當然，當有些公共方法，各個子類均有一致需求，此時就不應使用接口，使用抽象類。
11. 狀態模式
一個方法的判斷邏輯太長，就不容易修改。方法過長，其本質就是，就是本類在不同條件下的狀態轉移。狀態模式，就是將這些判斷分開到各個能表示當前狀態的獨立類中。
12. 備忘錄模式
備忘錄模式：事實上我覺得這個東西沒什么用，安照這種方式進行備份，會因為值類型與引用類型的不同而導致數據丟失。
13. 適配器模式
適配器模式：其實就是代理模式的一個變種，代碼的編寫方式都差不多。只是，使用這兩種模式的出發點不一樣，導致這兩種模式產生了細微的差別。
14. 組合模式
當對象或系統之間出現部分與整體，或類似樹狀結構的情況時，考慮組合模式。相對裝飾模式來說，這兩個有異曲同工之妙，都強調對象間的組合，但是，裝飾模式同時強調組合的順序，而組合模式則是隨意組合與移除。
15. 單例模式
能避免同一對象被反復實例化。比如說，訪問數據庫的連接對象就比普通對象實例化的時間要長;WCF中，維護服務器端遠程對象的創建等，這類情況，很有必要用單例模式進行處理對象的實例化。
16. 迭代器模式
提供一種方法訪問一個容器對象中各個元素，而又不需暴露該對象的內部細節。
Foreach就是這種模式應用的代表。
17. 職責鏈模式
職責鏈模式：就是一個將請求或命令進行轉發的流程，類似工作流。並且，也非常類似狀態模式，它們共同的特點就是將一個復雜的判斷邏輯，轉移到各個子類，然后在由子類進行簡單判斷。
狀態模式與職責鏈模式的區別：狀態模式是讓各個狀態對象自己知道其下一個處理的對象是誰，即在編譯時便設定好了的；而職責鏈模式中的各個對象並不指定其下一個處理的對象到底是誰，只有在客戶端才設定。
18. 命令模式
當有客戶端發送了一系列的命令或請求，去要求某個對象實現什么操作，可使用命令模式，相當於多個命令發給一個對象。
這一點和觀察者模式非常的類似。觀察者模式也是某個對象，發出消息，然后由中間對象通知觀察者然后去做什么，封裝的是要執行操作的對象。而命令模式，則是將各個操作封裝成類，然后告知某個對象該做什么。兩者的區別是封裝的角度不同。
19. 橋接模式
依據合成/聚合原則，優先使用類之間的不同組合，來實現各個類要表現的功能,而不是使用繼承。比如說：繼承會延續父類的功能，然而，並不是所有的子類都需要這樣的功能，但是抽象出的東西在父類，導致子類又必須要實現它，這樣，父類就越來越龐大，子類又多了很多不必要的東西。因此，橋接模式更強調類之間的組合從而實現解耦。
對比組合模式，它更強調的是部分與整體間的組合，橋接模式強調的是平行級別上不同類的組合。
20. 解釋器模式
舉例：寫好了C#代碼，VB代碼，此時需要個編譯器來編譯。這時，這個編譯器就相當於解釋器，解釋好了交給CPU執行。
解釋器跟適配器模式有點類似，但是，適配器模式不需要預先知道要適配的規則，解釋器是根據規則去執行解釋。
21. 享元模式
享元模式其實是為了避免創建過多的數據對象。比如此列：在象棋中只有紅黑雙方，紅棋子只是紅棋中的一顆，很多紅棋其實可以使用一個紅棋對象表示即可，在外部只需公開該棋的狀態即可區分那個紅棋，從而達到減少內存消耗的目的。
22.中介者模式
中介者模式：中介者類唯一要干的事情就是給各個成員對象發出通知。因此，中介者事先就應該知道有哪些成員。
中介者模式和代理模式，觀察者模式非常的像。但是其它兩種模式在調用的時候，並不需要事先設置那個類被代理，或是事先那些對象需要被通知。
23. 訪問者模式
在不改變原有代碼的結構上，又想去影響原來的類，或是訪問原來類的成員，此時就可以使用訪問者模式。但需要注意的是：事先需要構造好那些要訪問的對象的對象結構。這個結構在訪問者類中去維護。
24. 觀察者模式
就是消息訂閱--發布模式。本來原始的狀況是需要在觀察者類內部設置需要通知的對象。結果現在出現了事件。定義委托來通知其他對象，顯得更簡潔。
轉帖自：23種設計模式對比與總結