小引
最近在讀<<大話設計模式>>,也剛好自己的本科畢業設計是有關設計模式的內容,所以把本書的大概的內容通讀了一遍,希望在本書當作自己初認識設計模式的開始階段,想必大家都聽說宮保雞丁如何制作吧,他是經過不斷實踐、思考、總結，最后得到最佳的烹飪方法,而程序設計也如此,有方法,程序不是有生俱來的,也不是一種發明,他是利用前人的經驗，使解決問題不需要從頭解決,設計模式也由此而生了,使得程序重用性和可維護性提高
主要內容：
- 設計模式概述
- 設計模式分類
- 設計模式作用
- 可重用性
- 簡單工廠模式
- 策略模式
- 單一職責原則
- 開放-封閉原則
- 依賴倒轉原則
- 裝飾模式
- 代理模式
- 工廠方法模式
- 原型模式
- 模板方法模式
- 迪米特法則
- 外觀模式
設計模式概述
設計模式通常是對於某一類軟件設計問題的可重用的解決方案，將設計模式引入軟件設計和開發過程，其目的在於要充分利用已有的軟件開發經驗，優秀的軟件設計師都知道，不是每個問題都有從頭開始解決，而是復用以前曾經使用過的解決方案，每當找到一個好的方案了，就一遍一遍在使用，熟練了，設計模式的目標就是幫助人們利用成功軟件的集體開放經驗，做出更加好的解決產品。
1、Abstract Factory：提供一個創建一系列相關或相互依賴對象的接口，而無需指定它們具體的類。
2、Adapter：將一個類的接口轉換成客戶希望的另外一個接口。A d a p t e r模式使得原本由於接口不兼容而不能一起工作的那些類可以一起工作。
3、Bridge：將抽象部分與它的實現部分分離，使它們都可以獨立地變化。
4、Builder：將一個復雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。
5、Chain of Responsibility：為解除請求的發送者和接收者之間耦合，而使多個對象都有機會處理這個請求。將這些對象連成一條鏈，並沿着這條鏈傳遞該請求，直到有一個對象處理它。
6、Command：將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進行參數化；對請求排隊或記錄請求日志，以及支持可取消的操作。
7、Composite：將對象組合成樹形結構以表示“部分-整體”的層次結構。它使得客戶對單個對象和復合對象的使用具有一致性。
8、Decorator：動態地給一個對象添加一些額外的職責。就擴展功能而言， 它比生成子類方式更為靈活。
9、Facade：為子系統中的一組接口提供一個一致的界面， F a c a d e模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。
10、Factory Method：定義一個用於創建對象的接口，讓子類決定將哪一個類實例化。Factory Method使一個類的實例化延遲到其子類。
11、Flyweight：運用共享技術有效地支持大量細粒度的對象。
12、Interpreter：給定一個語言, 定義它的文法的一種表示，並定義一個解釋器, 該解釋器使用該表示來解釋語言中的句子。
13、Iterator：提供一種方法順序訪問一個聚合對象中各個元素, 而又不需暴露該對象的內部表示。
14、Mediator：用一個中介對象來封裝一系列的對象交互。中介者使各對象不需要顯式地相互引用，從而使其耦合松散，而且可以獨立地改變它們之間的交互。
15、Memento：在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象之外保存這個狀態。這樣以后就可將該對象恢復到保存的狀態。
16、Observer：定義對象間的一種一對多的依賴關系,以便當一個對象的狀態發生改變時,所有依賴於它的對象都得到通知並自動刷新。
17、Prototype：用原型實例指定創建對象的種類，並且通過拷貝這個原型來創建新的對象。
18、Proxy：為其他對象提供一個代理以控制對這個對象的訪問。
19、Singleton：保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。
20、State：允許一個對象在其內部狀態改變時改變它的行為。對象看起來似乎修改了它所屬的類。
21、Strategy：定義一系列的算法,把它們一個個封裝起來, 並且使它們可相互替換。本模式使得算法的變化可獨立於使用它的客戶。
22、Template Method：定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。Template Method使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。
23、Visitor：表示一個作用於某對象結構中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用於這些元素的新操作。
設計模式分類
1、目的划分
創建型（Creational）：與對象創建有關
結構行(Structural)：處理類和對象的組合
行為型（Behavioral）:描述類或者對象如何交互和如何分配職責
2、范圍划分
類模式：用於處理類和子類的關系，這些關系通過繼承建立，是靜態的，在編譯的就已經確定下來了，當然幾乎所有的模式都是使用繼承機制，所以這里的“類模式”是指處理類間關系的模式
對象模式：用於處理對象間的關系，這些關系具有動態性，在運行的時候是可以變化的
| 范圍\的 創建型（Creational） 結構行(Structural)： 行為型（Behavioral） |
| 類 Simple Factory Adapter (CLASS) Interpereter Factory Method Template method 對象 Abstract Factory Adapter(OBJECT) Chain of Responsibility Builder Bridge Command Prototype Composite Iterator Singleton Decorator Meditor Facade Memento Flyweight Observer |
設計模式的作用
1、重用設計，自動帶來代碼重用
2、為設計代碼共同的詞匯，每個模式就是一個設計詞匯，使交流更加方便
3、在開發文檔的采用模式詞匯可以容易理解你的想法，理解為什么這樣子做，你多了些什么，使開發文檔更加容易
4、可以使重構系統變得容易，可以確保開發正確的代碼，並降低在設計或者實現當中出現錯誤的可能，同時可以重寫其他應用程序提供更好的系統框架
5、正確使用設計模式可以節省大量時間
可重用性
•傳統的可重用性:包括代碼復制粘貼;算法重用,如：排序算法等;數據結構重用 如：隊列、數組等
- 面向對象：可維護、可復用、可擴展、靈活性好
- 業務封裝：業務邏輯與界面邏輯分開，讓它們的耦合 度下降
- 面向對象三大特性：封裝，繼承，多態
- URL類圖：注意前面的符號，“+”表示public，“-”表示 private，“#”表示protected
- 繼承、接口、關聯、聚合、合成（組合）、依賴
- 簡單工廠模式可以解決對象的創建問題
策略模式
- 策略模式（Strategy）：它定義了算法家族，分別封裝起來，讓它們之間可以互 相替換，此模式讓算法的變化不會影 響到算法的客戶。
- 策略模式是一種定義一系列算法的方法，從概念上來看，所有這些算法完成的都是相同的工 作，只是實現不同，它可以以相同的 方式調用所有的算法，減少了各種算法類與使用算法類之間的耦合。
- 策 略模式的Strategy類層次為Context定義了一系列的可供重用的算法或行為。繼承有助於析取出這些算法中的公共功能。
- 策 略模式的優點是簡化了單元測試， 因為每個算法都有自己的類，可以通過自己的接口單獨測試。
- 當不同的行為堆砌在一個類中時，就很難避免使用條件語句來選擇合適的行為。 將這些行為封裝在一個個獨立的Strategy類中，可以在使用這些行為的類中消除條件語句。
- 策 略模式就是用來封裝算法的， 選擇所用具體實現的 職責由客戶端對象承 擔，並轉給策 略模式的Context對 象。
單一職責原則
- 單一職責原則：就一個類而言，應該僅有一個引起它變化的原因。
- 如 果一個類承擔的職責過多，就等於把這些職責耦合在一起，一個職責的變化可能會削弱或者抑制這個類完成其他職能的能力。這種耦合會導致脆弱的設計，當變化發 生時，設計會遭受到意想不到的破壞。
- 軟件設計真正要做的許多內容，就是發現職責並把那些職責相互分離。
- 如 果你能夠想到多於一個的動機去改變一個類，那么這個類就具 有多於一個的 職責。
開放-封閉原則
- 開放-封閉原則：就是說軟件實體（類、模 塊、函數等等）應該可以擴展， 但是不可修改。 兩個特征，對於擴展是開放的， 對於更改是封閉的。
- 怎 樣的設計才能面對需求的改變卻可以 保持相對穩定，從而使得系統可以在第一個版本以后不斷推出新的版本呢？
- 設計的時候，盡量讓這個類足夠好， 寫好了就不要去修改了，如果新需求來，我們增加一些類就完事了，原來的代碼能不動則不動。
- 無論模塊多么的“封閉”，都會存在一些 無法對之封閉的變化。既然不可能完全封閉，設計人員必須對於他設計的模塊應該對哪種變化封閉做出選擇。他必須先猜測出最有可能發生的變化種類，然后構造抽象來隔離那些變化。
- 在 我們最初編寫代碼時，假設變化不會發生。當變化發生時，我們就創建抽象來隔離以后發生的同類變化。
- 面對需求，對程序的改動是通 過增加新代碼進 行的，而不是更改現有的代碼。
依賴倒轉原則
- 依賴倒轉原則：抽象不應該依賴細節，細節應該依賴於抽象；針對接口編程，不要對實現編程。A. 高層模塊不應該依賴低層模塊。兩個都應該依賴抽象。B. 抽象不應該依賴細節。細節應該依賴 抽象。
- 里氏替換原則：子類型必須能夠替換掉它們的父類型。
- 只 有當子類可以替換掉父類，軟件單位的功能不受到影響時，父類才能真正被復用，而子類也能夠在父類的基礎上增加新的行為。
- 由 於子類型的可替換性才使得使用父類類型的模塊在無需修改的情況下就可以擴展。
- 依賴倒轉其實可以說是面向對象設計的標志，如果編寫時考慮的都是 如何針對抽象編程而不是針對細節編程，即程序中所有的依賴關系都是終止於抽象類或者接口，那就是面向對象的設計，反之就是過程化的設計了。
裝飾模式
- 動態地給一個對象添加一些額外的職責，就增加功能來說， 裝飾模式比生成子類更為靈活。
- 裝飾模式是利用SetComponent來對對象進行包裝的。
- 每 個裝飾對象的實現就 和如何使用這個對象分 離開了，每個裝飾對象只關心自己的功能，不需要關心如何被添加到對象鏈當中。
- 裝飾模式是為已有功能動態地添加更多功能的一種方式。
- 當 系統需要新功能的時候，是向舊的類 中添加新的代碼，在主類中加入了新的字段，新的方法和新的邏輯，從而增加了主類的復雜度；而裝飾模 式卻提供了一個非常好的解決方案，它把每個要裝飾的功能放在單獨的類中，並讓這個類包裝它所要裝飾的對象，因為， 當需要執行特殊行為時，客戶代碼就可以在運行時根據需要有選擇的、按順序地使用裝飾功能包裝對象了。
- 優點：把類中的裝飾功能從類中 搬移去除，這樣可以簡化原有的類； 有效地把類的核心職責和裝飾功能區分開了。而且可以去除相關類中重復的裝飾邏輯。
代理模式
- 代理模式：為其他對象提供一種代理以控制對這個對象的訪問。
- 應 用場合：第一、遠程代理， 也就是為了一個對象在不同的地址空間提供局部代表。這樣可以隱藏一個對象存在於不同地址空間的事實（調用WebService）； 第二、虛擬代理， 是根據需要創建開銷很大的對象。通過它來存放實例化需要很長的時間的真實對象（瀏覽網頁，文字先下，圖片后下，使用代理）；第三、安全代理，用來控制真實對象 訪問時的權限； 第四、智能指引， 是指當調用真實的對象時，代理處理 另外一些事。
- 代理就是真實對象的代表。
工廠方法模式
- 簡單工廠模式的最大優點在於工廠類中包含了必要的邏輯判斷，根據客戶端的 選擇條件動態實例化相 關的類，對於客戶端來說，去除了與具體產品中的依賴。
- 工廠方法模式：定義一個用於創建對象的接口，讓子類決定實例化哪一個類。工 廠方法使一個類的實例化延遲到其子 類。
- 工廠方法模式實現時，客戶端需要決定實例化哪一個工廠來實現運算類，選擇判斷的問題還是存在的，也就 是說，工廠方法把簡單工廠的內部邏 輯判斷移到了客戶端代碼來進行。你想要加功能，本來是改工廠類，而現在是修改客戶端。
原型模式
- 原型模式：用原型實例指定創建對象的種類，並且通過拷貝這些原型創建新的對象。
- 原 型模式其實就是從一個對象再創建另 外一個可定制的對象，而且不需知道任何創建的細節。
- 一般在初始化的信息不發生變化的情況 下，克隆是 最好的辦法。這既隱藏了對象創建的細節，又對性能是大大的提高。
- MemberwiseClone()方法是這樣，如果字段是值類型的，則對該字段 執行逐位復制， 如果字段是引用類型， 則復制引用但 不復制引用的對象；因此，原始對象 及其復本引用同一對象。
- “淺復制”，被復制對象的所有變量都含有與原來的對象相同的值，而所有的對其他對象的 引用都仍然指向原來的對象，所以我們需要把要復制的對象所引用的對象都復制一遍，這種方式就是“深復制”，深復制把引用對象的 變量指向復制過的新對象，而不是原有的被引用的對象。
模版方法模式
- 我 們既然用了繼承，並且肯定這個繼承有 意思，就應該要成為子類的模板， 所有重復的代碼都 應該要上升到父類去， 而不是讓每個子類都去重復。
- 當 我們要完成在某一細節層次一致的 一個過程或一系列步驟，但其個別步 驟在更詳細的層次上的實現可能不同時，我們通常考慮用模板方法模式來處理。
- 模板方法模式：定義一個操作中的算法 的骨架，而將一些步驟延遲到子類中。 模板方法使得子類可以不改變一個算 法的結構即可重定義該算法的某些特定步驟。
- 模板方法模式是通過把不變行為搬移到超類，去除子類中的重復代碼來體現 它的優勢。
- 模板方法模式就是提供了一個很好的代碼復用平台。
- 當不變的和可變的行為在方法的子類實現中混合在一起的時候， 不變的行為就會在子類中重復出現。我們通過模板方法模式把這些行為搬移到單一的地方，這樣就幫助子類擺脫重復的不變行為的糾纏。
迪米特法則
- 迪米特法則也叫最少知識原則：如果兩個類不必 彼此直接通信，那么這兩個類就不應當發生直接的交互作用。如果其中一個類需要調用另一個類的某一個方法的話，可以通過第三者轉發這個調用。
- 首 先強調的前提是在類的結構設計上，每一個類都應當盡量降低成員的訪問權限。
- 迪米特法則其根本思想，是強調了類之間的松耦合。
- 類 之間的耦合越弱，越有利於復用，一個處在弱耦 合的類被修改，不會對有關系的類造 成波及。
- 信息的隱藏促進了軟件的復用。
外觀模式
- 外 觀模式：為子系統的一組接口提供一個一致的界面，此模式定義了一個高層接口，這個接口使得這子系統更加容易使用
- 首先，在設計的時候，應該有意識低將不同的兩個層分離，比如三層架構，就需要在數據訪問層的和業務邏輯層，表現層的層與層之間建立外觀的Facade
- 其次，在開發階段，子系統往往因為不斷的重構演化而變得越來越復雜，增加外觀Facade可以提供一個簡單的接口，減少他們之間的依賴
- 最后，維護一個遺留的大型系統時，可能這個系統已非常難以維護和擴展，你可以用外觀模式，當然你在為新系統開發一個外觀Facade類，來提供設計粗糙或者高度復雜的遺留代碼的比較清閑簡單的接口，讓新系統與Facade對象交互，Facade與遺留代碼交互所有復雜的工作
后記
本文雖然沒有詳細介紹各種具體的設計模型，而是總結大話設計模式當中的結論性的語句，但是在各個大標題下也總結了與具體設計模式類似的方法，往后有時間在詳細介紹常見的設計模式！ 主要參考：
C# 23種設計模式匯總：http://bbs.51aspx.com/showtopic-43429.html
大話設計模式
深入淺出設計模式
作者：類菌體
出處：http://www.cnblogs.com/bacteroid/archive/2012/03/21/2410704.html
關於作者：在校學生
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接
如有問題，可以通過303323670@qq.com 聯系我，非常感謝。