一、軟件設計模式的概念與意義
1. 軟件設計模式的概念
軟件設計模式（Software Design Pattern），又稱設計模式（Design Pattern），是一套被反覆使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。它描述了在軟件設計過程中的一些不斷重複發生的問題，以及該問題的解決方案。也就是說，它是解決特定問題的一系列套路，是前輩們的代碼設計經驗的總結，具有一定的普遍性，可以反覆使用。其目的是爲了提高代碼的可重用性、代碼的可讀性和代碼的可靠性。
2. 學習設計模式的意義
設計模式的本質是面向對象設計原則的實際運用，是對類的封裝性、繼承性和多態性以及類的關聯關係和組合關係的充分理解。正確使用設計模式具有以下優點。
- 可以提高程序員的思維能力、編程能力和設計能力。
- 使程序設計更加標準化、代碼編制更加工程化，使軟件開發效率大大提高，從而縮短軟件的開發週期。
- 使設計的代碼可重用性高、可讀性強、可靠性高、靈活性好、可維護性強。
因此設計模式並不是Java語言的專利，它同樣適用於 C++、C#、JavaScript 等其它面向對象的編程語言。
當然，軟件設計模式只是一個引導。在具體的軟件幵發中，必須根據設計的應用系統的特點和要求來恰當選擇。對於簡單的程序開發，可能寫一個簡單的算法要比引入某種設計模式更加容易。但對大項目的開發或者框架設計，用設計模式來組織代碼顯然更好。
二、軟件設計模式的基本要素
軟件設計模式使人們可以更加簡單方便地複用成功的設計和體系結構，它通常包含以下幾個基本要素：模式名稱、別名、動機、問題、解決方案、效果、結構、模式角色、合作關係、實現方法、適用性、已知應用、例程、模式擴展和相關模式等，其中最關鍵的元素包括以下 4 個主要部分。
1. 模式名稱
每一個模式都有自己的名字，通常用一兩個詞來描述，可以根據模式的問題、特點、解決方案、功能和效果來命名。模式名稱（PatternName）有助於我們理解和記憶該模式，也方便我們來討論自己的設計。
2. 問題
問題（Problem）描述了該模式的應用環境，即何時使用該模式。它解釋了設計問題和問題存在的前因後果，以及必須滿足的一系列先決條件。
3. 解決方案
模式問題的解決方案（Solution）包括設計的組成成分、它們之間的相互關係及各自的職責和協作方式。因爲模式就像一個模板，可應用於多種不同場合，所以解決方案並不描述一個特定而具體的設計或實現，而是提供設計問題的抽象描述和怎樣用一個具有一般意義的元素組合（類或對象的 組合）來解決這個問題。
4. 效果
描述了模式的應用效果以及使用該模式應該權衡的問題，即模式的優缺點。主要是對時間和空間的衡量，以及該模式對系統的靈活性、擴充性、可移植性的影響，也考慮其實現問題。顯式地列出這些效果（Consequence）對理解和評價這些模式有很大的幫助。
三、常見設計模式分類
設計模式有兩種分類方法，即根據模式的目的來分和根據模式的作用的範圍來分。
1. 根據目的來分
根據模式是用來完成什麼工作來劃分，這種方式可分爲創建型模式、結構型模式和行爲型模式 3 種。
-
創建型模式：用於描述“怎樣創建對象”，它的主要特點是“將對象的創建與使用分離”。如單例模式、原型模式、工廠方法模式、抽象工廠模式、建造者模式等 5 種創建型模式。
-
結構性模式：用於描述如何將類或對象按某種佈局組成更大的結構。如代理模式、適配器模式、橋接模式、裝飾模式、外觀模式、享元模式、組合模式等 7 種結構型模式
-
行爲型模式：用於描述類或對象之間怎樣相互協作共同完成單個對象都無法單獨完成的任務，以及怎樣分配職責。如模板方法模式、策略模式、命令模式、職責鏈模式、狀態模式、觀察者模式、中介者模式、迭代器模式、訪問者模式、備忘錄模式、解釋器模式等 11 種行爲型模式。
2. 根據作用範圍來分
根據模式是主要用於類上還是主要用於對象上來分，這種方式可分爲類模式和對象模式兩種。
-
類模式：用於處理類與子類之間的關係，這些關係通過繼承來建立，是靜態的，在編譯時刻便確定下來了。如工廠方法模式、（類）適配器模式、模板方法模式、解釋器模式屬於該模式。
-
對象模式：用於處理對象之間的關係，這些關係可以通過組合或聚合來實現，在運行時刻是可以變化的，更具動態性。常見23種設計模式中除了以上 4 種，其他的都是對象模式。
四、面向對象設計模式七大原則
| 原則名稱 | 簡單定義 |
|---|---|
| 開閉原則（Open Closed Principle，OCP） | 對擴展開放，對修改關閉。即軟件中的對象（類，模塊，函數等等）應該對於擴展是開放的，但是對於修改是封閉的。 |
| 單一職責原則（Single Responsibility Principle, SRP） | 對功能進行分類，代碼進行解耦，一個類只負責一個功能領域中的相應職責。 |
| 里氏替換原則（Liskov Substitution Principle，LSP） | 確保超類所擁有的性質在子類中仍然成立。即子類可以擴展父類的功能，但儘量不要改變父類原有的功能 |
| 依賴倒置原則（Dependence Inversion Principle，DIP） | 依賴於抽象，不能依賴於具體實現（面向接口編程） |
| 接口隔離原則（Interface Segregation Principle，ISP） | 儘量將臃腫龐大的接口拆分成更小的和更具體的接口，一個類對另一個類的依賴應該建立在最小的接口。即要爲各個類建立它們需要的專用接口，而不要試圖去建立一個很龐大的接口供所有依賴它的類去調用。 |
| 迪米特法則（Law of Demeter，LoD）又稱最少知識原則（Least Knowledge Principle，LKP) | 只與你的直接朋友交談，不跟“陌生人”說話。即如果兩個軟件實體無須直接通信，那麼就不應當發生直接的相互調用，可以通過第三方轉發該調用。其目的是降低類之間的耦合度，提高模塊的相對獨立性。 |
| 合成複用原則（Composite Reuse Principle，CRP）又稱組合/聚合複用原則（Composition/Aggregate Reuse Principle，CARP） | 要儘量先使用組合或者聚合等關聯關係來實現，其次才考慮使用繼承關係來實現 |