0. 前言

設計模式（Design pattern）是一套被反覆使用、多數人知曉的、經過分類編目的、程式碼設計經驗的總結。

使用設計模式是為了可重用程式碼、讓程式碼更容易被他人理解、保證程式碼可靠性。

設計模式於己於他人於系統都是多贏的，設計模式使程式碼編制真正工程化，設計模式是軟體工程的基石，如同大廈的一塊塊磚石一樣。

專案中合理的運用設計模式可以完美的解決很多問題，每種模式在現在中都有相應的原理來與之對應，每一個模式描述了一個在我們周圍不斷重複發生的問題，以及該問題的核心解決方案，這也是它能被廣泛應用的原因。

0.1 UML圖

統一建模語言（Unified Modeling Language，UML）

詳見之前一篇文章UML類圖

1. 設計模式的三大分類

共有23種設計模式，可以分為3類：

• 建立型（Creational）：
• 結構型（Structural）：
• 行為型（Behavioral）：

(1) 建立型（5種）

• 工廠方法模式（Factory Method） 重要程度：5
• 抽象工廠模式（Abstract Factory） 重要程度：5
• 簡單工廠模式（Simple Factory） 重要程度：4 （後來新增的）
• 單例模式（Singleton） 重要程度：4
• 原型模式（Prototype） 重要程度：3
• 建造者模式（Builder） 重要程度：2

• 外觀模式（Facade） 重要程度：5
• 介面卡模式（Adapter） 重要程度：4
• 組合模式（Composite） 重要程度：4
• 代理模式（Proxy） 重要程度：4
• 裝飾模式（Decorator） 重要程度：3
• 橋接模式（Bridge） 重要程度：3
• 享元模式（Flyweight） 重要程度：1

• 觀察者模式（Observer） 重要程度：5
• 迭代器模式（Iterator） 重要程度：5
• 命令模式（Command） 重要程度：4
• 策略模式（Stragety） 重要程度：4
• 責任鏈模式（Chain of Responsibility） 重要程度：3
• 狀態模式（State） 重要程度：3
• 模板方法模式（Template Method） 重要程度：3
• 中介者模式（Mediator） 重要程度：2
• 備忘錄模式（Memento） 重要程度：2
• 直譯器模式（Interpreter） 重要程度：1
• 訪問者模式（Visitor） 重要程度：1

定義：所有引用基類的地方必須能透明地使用其子類的物件。

通俗地講：只要父類能出現的地方子類就能出現，而且替換為子類也不會產生任何錯誤或異常。反之就不行了，有子類出現的地方，父類未必就能適應。

好處：增強程式的健壯性，即使增加了子類，原有的子類還可以繼續執行。

需要注意：如果子類不能完整地實現父類的方法，或者父類的某些方法在子類中已經發生“畸變”，則建議斷開父子繼承關係 採用依賴、聚合、組合等關係代替繼承。

(3) 依賴倒置原則（Dependence Inversion Principle, DIP）

定義：高層模組不應該依賴底層模組，兩者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。

通俗地講：模組間的依賴通過抽象產生，實現類之間不發生直接的依賴關係，其依賴關係是通過介面或抽象類產生的。

好處：擴充套件性提高、解耦

需要注意：依賴倒置原則指代了一種特定的解耦形式，使得高層次的模組不依賴與低層次的模組的實現細節的目的。

(4) 介面隔離原則（Interface Segregation Principle, ISP）

定義：類之間的依賴關係應該建立在最小的介面上。

通俗地講：建立單一介面，不要建立龐大臃腫的介面；儘量細化介面，介面中的方法儘量少。

也就是說，我們要為各個類建立專用的介面，而不要試圖去建立一個很龐大的介面供所有依賴它的類去呼叫。

需要注意：

• 介面儘量小，但是要有限度。對介面進行細化可以提高程式設計靈活性，但是如果過小，則會造成介面數量過多，使設計複雜化，所以一定要適度。
  
• 提高內聚，減少對外互動。使介面用最少的方法去完成最多的事情。
  
• 為依賴介面的類定製服務。只暴露給呼叫的類它需要的方法，它不需要的方法則隱藏起來。只有專注地為一個模組提供定製服務，才能建立最小的依賴關係。

(5) 迪米特定律（Law of Demeter, LoD）

也稱為最少知識原則（Least Knowledge Principle）

定義：一個物件應該對其他物件有最少的瞭解。

通俗地講：一個類應該對自己依賴的類知道得越少越好。

自從我們接觸程式設計開始，就知道了軟體程式設計的總的原則：低耦合，高內聚。

無論是面向過程程式設計還是面向物件程式設計，只有使各個模組之間的耦合儘量的低，才能提高程式碼的複用率。

低耦合的優點不言而喻，但是怎麼樣程式設計才能做到低耦合呢？那正是迪米特法則要去完成的。

(6) 開閉原則（Open Close Principle, OCP）

定義：軟體中的物件（類、模組、函式等）應該對於擴充套件是開放的，但是，對於修改是封閉的。

通俗地講：在軟體的生命週期內，變化（升級和維護等）一定會發生。當軟體需要變化時，應該儘量通過擴充套件的方式來實現變化，而不是通過修改已有的程式碼來實現。

然而，在實際的開發過程中，修改原有程式碼、擴充套件程式碼往往是同時存在的。