轉載：http://blog.csdn.net/u013798619

第一次讀《大話設計模式》，是在剛接觸C#的時候。疲累於大部頭的官方教材中時，無意間翻開了這本生動有趣的書，甚是眼前一亮。由於當時C#基礎薄弱，只是把它當小說來看，如饑似渴，饒有滋味，一口氣看到淩晨四點，被不知覺間流逝的時間嚇傻了。

而今重讀，更多的是想重溫設計模式的應用場景和感受小菜對編程的熱忱。一邊做筆記一邊看書，初步弄懂UML類圖，效率果然高很多。感動也頗多。師傅領進門，修行看個人呀。

對程序員來說，精彩的代碼是如何想出來的，要比看到精彩的代碼更加令人期待。正如做一個足球運動員（軟件設計編程者），能夠親自上場比賽，並且最終成為球星（軟件架構師），會遠比做一個助威吶喊的球迷（軟件使用者&代碼崇拜者）更來得激動人心。

那麽如何才能想出精彩的代碼呢？歷練使人成長，經驗迸發靈感。然而所有的靈感都應有其因，那就是萬變不離其宗的六大面向對象的設計原則，即單一職責原則、開放--封閉原則、依賴倒轉原則、裏氏代換原則、迪米特法則和合成--聚合復用原則。但這六大原則僅僅是一系列的“口號”，真正付諸實施還需要有詳盡的指導方法，於是23種設計模式應運而生。歸根到底，就是通過重構改善既有代碼，使代碼的耦合度降低，最終實現易維護、易擴展、易復用和靈活性好的編程設計，得到精彩的代碼。

編程是一門技術，更是一門藝術。只懂編程技術的程序員是代碼工人，被稱為碼農；然而編程絕不僅僅指編程技術的熟練掌握，而應指站在一個更高的層次去欣賞程序代碼、軟件設計、架構，完成從碼農到架構師的蛻變。因此我們需要學習設計模式。設計模式是軟件行業的經驗總結，因此具有更廣泛的適應性，不管使用什麽編程語言，也不管遇到什麽業務類型，設計模式都可以自由地“侵入”。

深知設計模式應該從大量的實戰經驗中來，若沒有大量立即付諸實踐的場景是不能說理解設計模式。實戰中理解設計模式將是我的最終的奮鬥目標。在入門伊始，初期目標是對設計模式有一個初步的了解。

寫這篇文章的主要目的，是為了記錄我此時的學習狀態和心得，以便日後回顧。同時也培養邊看書邊做筆記的好習慣。下列的Story均為《大話設計模式》中的實踐場景。

下面切入正題：（6種設計原則&23種設計模式）

一.六種設計原則（核心：強內聚，松耦合）

1.單一職責原則

Story：手機功能齊全，但一在關鍵時刻就“萎”掉；

Concept：就一類而言，應該只有一個引起它變化的原因，體現了類的職責分離。

Tips：如mvc架構，實現邏輯和界面的分離。

2.開放--封閉原則

Story：考研&找工作兩手抓，香港澳門一國兩制；

Concept：是所有面向對象原則的核心。軟件實體應該是可擴展，而不可修改的。即對擴展是開放的，而對修改是封閉的。

Tips：應該僅對程序中呈現出頻繁變化的那些部分做出抽象，拒絕不成熟的抽象和抽象本身一樣重要。

3.依賴倒轉原則

Story：修電腦門檻低，因為PC電腦的主板、CPU和內存等針對接口設計，而不是針對實現設計，耦合程度低，依賴性弱，易維修；而收音機過多強耦合開發，難排查，難維修；

Concept：高層模塊不應該依賴低層模塊，兩者都應該依賴其抽象；抽象不應該依賴細節，細節應該依賴抽象；

Tips：（1）應針對接口編程，不要對實現編程；因為針對實現來設計內存，就要對應到具體的某個品牌的主板，那會出現換內存需要把主板也換了的尷尬；

（2）依賴倒轉原則其實是面向對象設計的標誌。若編寫時考慮的都是針對抽象編程即為面向對象設計；反之，針對細節編程即為過程化的設計；

4.裏氏代換原則

Story：繼承關系，如鳥類&企鵝類；

Concept：在軟件中，把父類都替換成它的子類，而程序的行為沒有變化。子類型必須能夠替換他們的父類型；正是由於子類型的可替換性才使得使用父類型的模塊在無需修改的情況下就可以擴展；

Tips：裏氏代換原則是對開放--封閉原則的補充。實現開放--封閉原則的關鍵步驟就是抽象化。而基類與子類的繼承關系就是抽象化的具體實現，所以裏氏代換原則是對實現抽象化的具體步驟的規範。

5.迪米特法則

Story：無熟人難辦事，主要是處理權限問題；

Concept：也叫最少知識原則。類之間的耦合越弱，就越有利於復用，一個處在弱耦合的類被修改，不會對有關系的類造成波及。 主要是強調了類之間的松耦合；

Tips：在類的設計上，每一個類都應當盡量降低成員的訪問權限。

6.合成--聚合復用原則

Story：硬件廠商生產的硬件與軟件廠商生產的軟件為合成關系；手機品牌包含的手機軟件為聚合關系；

Concept：合成聚合是“has a”的關系，而繼承是“is a”的關系。由於繼承是一中強耦合的結構，父類變，子類必變。所以不是“is a”關系，我們一般不要用繼承。優先使用合成聚合復用原則，有助於保持每個類的封裝，降低繼承的層次。

Tips：盡量使用合成/聚合，盡量不使用類繼承。

二. 23種設計模式

A.創建型模式

1.簡單工廠模式

Story：計算器的功能設計與實現；

Concept：又叫做靜態工廠方法模式，是由一個工廠對象決定創建出哪一種產品類的實例；

Tips：提供一個創建一系列或相關依賴對象的接口，而無需指定它們具體的類。

2.建造者模式

Story：炒面沒放鹽，千家千味，而肯德基麥當勞千家一味；建造小人物；

Concept：將一個復雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。用戶只需要指定建造的類型，而無需知道具體建造的過程與細節。

Tips：Builder接口的對象是用於創建一些復雜的對象，這些對象內部構建間的建構順序通常是穩定的，但對象內部的構建通常面臨著復雜的變化。其好處就是，使建造代碼與表示代碼分離。

3.工廠方法模式

Story：學雷鋒，不留名，誌願者愛心行動相傳。

Concept：定義一個用於創建對象的接口，讓子類決定實例化哪一個類。工廠方法使一個類的實例化延遲到其子類。

4.原型模式

Concept：用原型實例指定創建對象的種類，並且通過拷貝這些原型創建新的對象；

Tips:主要用於對象的復制，它的核心是就是類圖中的原型類Prototype。使用原型模式的一個好處是簡化對象的創建，使得創建對象就像我們在編輯文檔時的復制粘貼一樣簡單。

5.單例模式

Concept：保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。

Tips：單例模式可讓類自身負責保存它的唯一實例。

B.結構型模式

6.適配器模式

Story：姚明在NBA需要翻譯；

Concept：將一個類的接口適配成用戶所期待的。包括類適配器模式和對象適配器模式；

Tips：主要應用於希望復用一些現存的類，但是接口又與復用環境要求不一致的情況。只有在無法改變原有設計和代碼的情況下才考慮適配；

7.橋接模式

Story：手機品牌不統一，軟件不兼容；

Concept：將抽象部分與它的實現部分分離，使他們都可以獨立地變化。

8.組合模式

Story：為有分銷機構的大公司做辦公管理系統；

Concept：將對象組合成樹形結構以表示“部分——整體”的層次結構。組合模式使得用戶對單個對象和組合對象的使用具有一致性；

Tips：使用條件為：當需求中體現部分與整體層次的結構時，以及你希望用戶可以忽略組合對象與單個對象的不同，統一地使用組合結構中的所有對象時；

9.裝飾模式

Story：穿何種服裝見女朋友；

Concept：每個裝飾對象的實現和如何使用這個對象分離開；

Tips：這樣做的最大好處就是有效地把類的核心職責和裝飾功能區分開，而且可以去除相關類中重復的裝飾邏輯。

10.外觀模式

Story：股票投資風險大，眾多投資者與眾多股票聯系太多，反而不利於操作；而基金是基金經理人與上千股票和其他投資產品打交道，風險更小；

Concept：為子系統中的一組接口提供一個一致的界面，此模式定義了一個高層接口，這個接口使得這一子系統更加容易使用；

Tips：使用情況：（1）在設計初期階段，應該要有意識地將不同的兩個層分離；（2）在開發階段，子系統往往因為不斷的重構演化而變得越來越復雜。若增加Fa?ade可以提供一個簡單的接口，以減少它們之間的依賴性；（3）在維護一個遺留的大型系統時，可能這個系統已經非常難以維護和擴展，這時，可以為新系統開發一個Fa?ade類，來提供設計粗糙或高度復雜和遺留代碼比較清晰的接口，讓新系統與Fa?ade對象交互，Fa?ade與遺留代碼交互所有復雜的工作；

11.亨元模式

Concept：以共享的方式高效地支持大量的細粒度對象；

Tips：1）享元模式使得系統更加復雜。為了使對象可以共享，需要將一些狀態外部化，這使得程序的邏輯復雜化；

12.代理模式

Story：卓賈易通過戴勵送嬌嬌東西，結果戴勵與嬌嬌戀愛了；

Concept：在訪問對象時引入一定程度的間接性，因為這種間接性，可以附加多種用途。

Tips：代理模式包括：遠程代理、虛擬代理、安全代理和智能指引；

C.行為型模式

13. 觀察者模式

Story：上班炒股，前臺秘書通風報信；要求前臺類與觀察者雙向耦合；

Concept：定義一種一對多的關系，讓多個觀察者對象同時監聽某一主題對象；

Tips：當不知道具體有多少對象有待改變時，應該考慮使用觀察者模式。實則在解耦合，讓耦合雙方都依賴於抽象，而不是依賴於具體；

14.模板方法模式

Story：看不懂英文試題，會做也白搭；

Concept：：在一個方法中定義一個算法的骨架，而將一些實現步驟延遲到子類中。模板方法使得子類可以在不改變算法結構的情況下，重新定義算法中的某些步驟；

15.命令模式

Story：打遊擊烤羊肉串的檔口對請求排隊或記錄請求日誌以及支持可撤銷操作，其實是“行為請求者”與“行為實現者”的緊耦合；做烤肉的開門店反之；

Concept：將一個請求封裝一個對象，從而使你可用不同的請求對客戶進行參數化，對請求排隊或記錄請求日誌以及支持可撤銷操作；

Tips：敏捷開發原則；

16.狀態模式

Story：不同時間人的精神狀態不同；

Concept：當一個對象的內在狀態改變時允許改變其行為，這個對象看起來像是改變了其類。

Tips：狀態模式主要解決的是當控制一個對象狀態的條件表達式過於復雜時的情況。把狀態的判斷邏輯轉移到表示不同狀態的一系列類中，可以把復雜的判斷邏輯簡化。其好處是，將與特定狀態相關的行為局部化，並且將不同狀態的行為分割開來；

17.職責鏈模式

Story：設計加薪代碼；

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

18.解釋器模式

Story：明白老板的評價背後潛臺詞；

Concept：如果一個特定類型的問題發生的頻率足夠高，那麽可能就值得將該問題的各個實例表述為一個簡單語言中的句子；

Tips：可構建一個解釋器通過解釋這些句子來解決該問題；

19.中介者模式

Story：安理會&聯合國等調停組織；

Concept：又叫調停者模式，定義一個中介對象來封裝系列對象之間的交互。中介者使各個對象不需要顯示地相互引用，從而使其耦合性松散，而且可以獨立地改變他們之間的交互。

20.訪問者模式

Story：man & woman的異同；

Concept：表示一個作用於某對象結構中的各元素的操作。它使你可以在不改變各元素類的前提下定義作用於這些元素的新操作。

Tips：目的是把處理從數據結構中分離出來；

21.策略模式

Story：商場促銷中各種折扣優惠的實現；

Concept：定義了一系列的算法，並將每一個算法封裝起來，而且使它們還可以相互替換，讓算法獨立於使用它的客戶而獨立變化；

Tips：優點是：簡化了單元測試；

22.備忘錄模式

Story：遊戲存儲進度；

Concept：在不破壞封閉的前提下，捕獲一個對象的內部狀態，並在該對象之外保存這個狀態。這樣以後就可將該對象恢復到原先保存的狀態。

Tips：涉及角色：發起人(Originator)、備忘錄(Memento)和管理者(Caretaker)；

23.叠代器模式

Story：售票員進行叠代遍歷檢票，不放過漏網之魚；

Concept：提供一種方法順序訪問一個聚合對象中各個元素，而又不需暴露該對象的內部表示；

Tips：分離了集合對象的遍歷行為，抽象出一個叠代器類來負責，這樣既可以做到不暴露集合的內部結構，又可以讓多部代碼透明地訪問集合內部的數據；

《大話設計模式》讀後感