設計模式(Design Patterns)的簡單講解

• 模式的誕生與定義

  ---

1. 模式(Pattern)起源於建築業而非軟件業(小本本記下來～～)
2. 模式之父--美國加利佛尼亞大學環境結構中心研究所所長Christopher Alexander博士;
3. 模式 ：

   -Context（模式可適用的前提條件）
   -Theme或Problem（在特定條件下要解決的目標問題）
   -Solution（對目標問題求解過程當中各類物理關係的記述）

4. 模式是在特定環境下人們解決某類重複出現問題的一套成功有效的解決方案（簡單來講就是爲了減小工做量）。
5. 程序設計的最大的特色：  變化   由於環境、設備、用戶的需求等緣由，  致使程序常常發生變化
6. 基本結構
7. 設計模式的定義：一套被反覆使用的，多數人知曉的，通過分類遍目的、代碼設計經驗的總結，使用設計模式是爲了可重複使用代碼，讓代碼更容易被他人理解而且提升代碼的可靠性(目的)。設計模式是一種對軟件系統中不斷重複出現的設計問題的解決方案進行文檔化的技術，也是一種共享專家設計經驗的技術。
8. 基本要素 ：模式名稱(Pattern Name)、問題(Problem) 、解決方案(Solution)、效果(Consequences)

• 設計模式的分類

  ---

1. 根據目的（模式是用來作什麼的）：可分爲建立型(Creational)，結構型(Structural)和行爲型(Behavioral)三類
2. 根據範圍，即模式主要是處理類之間的關係仍是處理對象之間的關係，可分爲類模式和對象模式兩種：
   1. 類模式處理類和子類之間的關係，這些關係經過繼承創建，在編譯時刻就被肯定下來，是一種靜態關係
   2. 對象模式處理對象間的關係，這些關係在運行時變化，更具動態性

• GoF設計模式

  ---

1.   「四人組(Gang of Four，GoF，分別是Erich Gamma, Richard Helm, Ralph Johnson和John Vlissides)」於1994年概括髮表了23種在軟件開發中使用頻率較高的設計模式，旨在用模式來統一溝通面向對象方法在分析、設計和實現間的鴻溝。

3. 建立型模式（關注對象的建立過程，對類的實例化過程進行抽象，描述如何將對象的建立和使用分離）
   抽象工廠模式(Abstract Factory) ★★★★★
   建造者模式(Builder) ★★☆☆☆
   工廠方法模式(Factory Method) ★★★★★(GoF 以外：簡單工廠模式)
   原型模式(Prototype) ★★★☆☆
   單例模式(Singleton) ★★★★☆

4. 結構型模式(關注如何將現有類或對象組織在一塊兒造成更增強大的結構)
   適配器模式(Adapter) ★★★★☆
   橋接模式(Bridge) ★★★☆☆
   組合模式(Composite) ★★★★☆
   裝飾模式(Decorator) ★★★☆☆
   外觀模式(Facade) ★★★★★
   享元模式(Flyweight) ★☆☆☆☆
   代理模式(Proxy) ★★★★☆

5. 行爲型模式(關注系統中對象間的交互，研究系統在運行時對象之間的相互通訊與協做進一步明確對象的職責)
   職責鏈模式(Chain of Responsibility) ★★☆☆☆
   命令模式(Command) ★★★★☆
   解釋器模式(Interpreter) ★☆☆☆☆
   迭代器模式(Iterator) ★★★★★
   中介者模式(Mediator) ★★☆☆☆
   備忘錄模式(Memento) ★★☆☆☆
   觀察者模式(Observer) ★★★★★
   狀態模式(State) ★★★☆☆
   策略模式(Strategy) ★★★★☆
   模板方法模式(Template Method) ★★★☆☆
   訪問者模式(Visitor) ★☆☆☆☆

• 經常使用面向對象設計的原則

  ---

1. 單一職責原則(Single Responsibility Principle, SRP)| ★★★★☆ : 一個對象應該只包含單一的職責，而且該職責被完整地封裝在一個類中 
   1. 另外一種定義方式：就一個類而言，應該僅有一個引發它變化的緣由。簡單而言，就是一個類若是職責越多，那麼它被複用的可能性就越低。即這個類中一個職責變化，可能會影響到其餘的職責的運做。所以，單一職責原則就是實現高內聚，低耦合，將一個類的職責下降到最小，即類的數目不少，類中職責不多，於是類被複用的可能性被提升。
2. 開閉原則(Open-Closed Principle,OCP) | ★★★★★ : 軟件實體應當對擴展開放，對修改關閉
   1. 開閉原則是複用設計的第一塊基石。在軟件實體中應在儘可能不修改原有代碼的狀況下進行擴展
3. 里氏代換原則(Liskov Substitution Principle,LSP)| ★★★★★ : 全部引用基類的地方必須能透明地使用其子類的對象 
   1. 在軟件中將一個基類對象替換成它的子類對象，程序將不會產生任何的錯誤和異常，反之不成立。例如：我喜歡動物，那麼我必定喜歡狗，由於狗是動物的子類，反之不成立
4. 依賴倒轉原則(Dependence Inversion Principle,DIP) |  ★★★★★ : 高層模塊不該該依賴低層模塊，它們應該依賴抽象。抽象不該該依賴於細節，細節應該依賴於抽象
   1. 要針對接口編程，不針對實現編程。一個具體類應當只實現接口或抽象類中聲明過的方法，而不給出多餘的方法，否在無調用到在子類中增長的新方法
5. 接口隔離原則(Interface Segregation Principle,ISP)| ★★☆☆☆ : 客戶端不該該依賴那些它不須要的接口 
   1. 當一個接口太大時，將它分割成一些更細小的接口，使用該接口的客戶端只要知道與之相關的方法便可
6. 合成複用原則(Composite Reuse Principle,CRP)| ★★★☆☆:優先使用對象組合，而不是繼承來達到複用的目的
   1. 在一個新的對象裏經過關聯關係(包括組合和聚合關係)來使用一些已有的對象，使之成爲新對象的一部分，新對象經過委派調用已有對象的方法達到複用功能的目的
7. 迪米特法則(Law of Demeter,LoD)| ★★★☆☆ : 每個軟件單位對其餘的單位都只有最少的知識，並且侷限於那些與本單位密切相關的軟件單位 
   1. 又稱最少知識原則，一個軟件實體應儘量少地與其餘類發生相互做用

• 設計模式的優勢
  

  ---

1. 　　融合了衆多專家的經驗，並以一種標準的形式供廣大開發人員所用
2. 　　提供了一套通用的設計詞彙和一種通用的語言，以方便開發人員之間進行溝通和交流，使得設計方案更加通俗易懂
3. 　　讓人們能夠更加簡單方便地複用成功的設計和體系結構
4. 　　使得設計方案更加靈活，且易於修改
5. 　　將提升軟件系統的開發效率和軟件質量，且在必定程度上節約設計成本
6. 　　有助於初學者更深刻地理解面向對象思想，方便閱讀和學習現有類庫與其餘系統中的源代碼，還能夠提升軟件的設計水平和代碼質量

• 設計模式的缺點

  ---

1. 　　要說缺點的話，每一種都有它適用的地方和不適用之處，若使用不當，缺點每每會暴露的很明顯。所以，學習到位，理解透徹，運用的多了，天然懂得如何揚長避短了，於是模式的缺點就儘量的最小化了