目錄
1、設計模式概念
設計模式，是一套被反覆使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是爲了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性、程序的重用性。每一個模式描述了一個在我們周圍不斷重複發生的問題，以及該問題的解決方案的核心。這樣，你就能一次又一次地使用該方案而不必做重複勞動。設計模式的核心在於提供了相關問題的解決方案，使得人們可以更加簡單方便地複用成功的設計和體系結構。
2、設計模式4個基本要素
（1）模式名稱（pattern name）一個助記名，它用一兩個詞來描述模式的問題、解決方案和效果。命名一個新的模式增加了我們的設計詞彙。設計模式允許我們在較高的抽象層次上進行設計。基於一個模式詞彙表，我們自己以及同事之間就可以討論模式並在編寫文檔時使用它們。模式名可以幫助我們思考，便於我們與其他人交流設計思想及設計結果。找到恰當的模式名也是我們設計模式編目工作的難點之一。
（2） 問題(problem) 描述了應該在何時使用模式。它解釋了設計問題和問題存在的前因後果，它可能描述了特定的設計問題，如怎樣用對象表示算法等。也可能描述了導致不靈活設計的類或對象結構。有時候，問題部分會包括使用模式必須滿足的一系列先決條件。
（3） 解決方案(solution) 描述了設計的組成成分，它們之間的相互關係及各自的職責和協作方式。因爲模式就像一個模板，可應用於多種不同場合，所以解決方案並不描述一個特定而具體的設計或實現，而是提供設計問題的抽象描述和怎樣用一個具有一般意義的元素組合（類或對象組合）來解決這個問題。
（4）效果(consequences) 描述了模式應用的效果及使用模式應權衡的問題。儘管我們描述設計決策時，並不總提到模式效果，但它們對於評價設計選擇和理解使用模式的代價及好處具有重要意義。軟件效果大多關注對時間和空間的衡量，它們也表述了語言和實現問題。因爲複用是面向對象設計的要素之一，所以模式效果包括它對系統的靈活性、擴充性或可移植性的影響，顯式地列出這些效果對理解和評價這些模式很有幫助。
3、設計模式分類
按照設計模式的目的可以分爲三大類：創建型模式、結構型模式、行爲型模式。
|
|
創建型 |
結構型 |
行爲型 |
|
|
簡單工廠模式(Singleton) 工廠方法模式(factory method) 抽象工廠模式(Abstract factory) 單例模式(Singleton) 原型模式(prototype) 建造者模式(Builder) |
適配器模式(Adapter) 裝飾者模式(decorator) 橋接模式(Bridge) 組合模式(composite) 享元模式(Flyweight) 代理模式(Proxy) 外觀模式(facade) |
策略模式(strategy) 觀察者模式(observer) 模板方法模式(Template) 命令模式(Command) 狀態模式(State) 責任鏈模式(Chain of responsibility) 解釋器模式(Interpreter) 中介者模式(Mediator) 訪問者模式(visitor) 備忘錄模式(Memento) 迭代器模式(iterator) |
4、設計模式原則
（1）單一職責原則（single responsibility principle，SPR）
一個類，只有一個引起它變化的原因。如果一個類承擔的職責過多，就等於把這些職責耦合在一起了。一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當發生變化時，設計會遭受到意想不到的破壞。而如果想要避免這種現象的發生，就要儘可能的遵守單一職責原則。此原則的核心就是解耦和增強內聚性。通俗一點：就是一個類越複雜，可能被複用的可能性越小；類越複雜，變動代碼可能會有意想不到的錯誤。
（2）開閉原則（Open-Close Principe，OCP）
開閉原則定義：一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉。
開放-封閉原則的意思就是說，你設計的時候，時刻要考慮，儘量讓這個類是足夠好，寫好了就不要去修改了，如果新需求來，我們增加一些類就完事了，原來的代碼能不動則不動。這個原則有兩個特性，一個是說“對於擴展是開放的”，另一個是說“對於更改是封閉的”。面對需求，對程序的改動是通過增加新代碼進行的，而不是更改現有的代碼。這就是“開放-封閉原則”的精神所在。
（3）里氏替換原則（Liskov Substitution Principe，LSP）
里氏替換原則(Liskov Substitution Principle LSP)面向對象設計的基本原則之一。 里氏替換原則中說，任何基類可以出現的地方，子類一定可以出現。 LSP是繼承複用的基石，只有當衍生類可以替換掉基類，軟件單位的功能不受到影響時，基類才能真正被複用，而衍生類也能夠在基類的基礎上增加新的行爲。
（4）依賴倒置原則（Dependence Inversion Principle）
依賴倒置原則是程序要依賴於抽象接口，不要依賴於具體實現。簡單的說就是要求對抽象進行編程，不要對實現進行編程，這樣就降低了客戶與實現模塊間的耦合。
面向過程的開發，上層調用下層，上層依賴於下層，當下層劇烈變動時上層也要跟着變動，這就會導致模塊的複用性降低而且大大提高了開發的成本。
面向對象的開發很好的解決了這個問題，一般情況下抽象的變化概率很小，讓用戶程序依賴於抽象，實現的細節也依賴於抽象。即使實現細節不斷變動，只要抽象不變，客戶程序就不需要變化。這大大降低了客戶程序與實現細節的耦合度。
（5）接口隔離原則（Interface Segregation Principle, ISP）
口隔離原則告訴我們，不要把一大堆方法塞進一個接口裏，導致這個接口變得臃腫無比。應該要根據實際需要，接口應該儘量細化，一個接口對應一個功能模塊，同時接口裏面的方法應該儘可能的少，使接口更加輕便靈活。或許看到接口隔離原則這樣的定義很多人會覺得和單一職責原則很像，但是這兩個原則還是有着很鮮明的區別。接口隔離原則和單一職責原則的審視角度是不同的，單一職責原則要求類和接口職責單一，注重的是職責，是業務邏輯上的劃分，而接口隔離原則要求方法要儘可能的少，是在接口設計上的考慮。例如一個接口的職責包含10個方法，這10個方法都放在一個接口中，並且提供給多個模塊訪問，各個模塊按照規定的權限來訪問，並規定了“不使用的方法不能訪問”，這樣的設計是不符合接口隔離原則的，接口隔離原則要求“儘量使用多個專門的接口”，這裏專門的接口就是指提供給每個模塊的都應該是單一接口(即每一個模塊對應一個接口)，而不是建立一個龐大臃腫的接口來容納所有的客戶端訪問。
（6）迪米特原則（Law of Demeter）
又稱爲最少知識原則（Least Knowledge Principle，LKP），一個類對於其他類知道的越少越好，就是說一個對象應當對其他對象有儘可能少的瞭解。迪米特法則的意義在於降低類之間的耦合。由於每個對象儘量減少對其他對象的瞭解，因此，很容易使得系統的功能模塊功能獨立，相互之間不存在（或很少有）依賴關係。