一、設計模式概述
設計模式，是一套被反覆使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是爲了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性、程序的重用性。
設計模式其實就是開發過程中常見問題的解決方案，是解決問題的思路。學習設計模式能更優雅的解決面向對程序開發設計問題。
二、面向對象23種設計模式
創建型模式
關注對象的創建
| 模式名稱 | 中文名稱 | 基本定義 |
|---|---|---|
| Singleton | 單例模式 | 保證一個類僅有一個實例，並且提供一個全局訪問點。 |
| Factory Method | 工廠方法模式 | 定義一個用於創建對象的接口，讓子類決定將哪一個類實例化。工廠方法模式使一個類的實例化延遲到子類。 |
| Abstract Factory | 抽象工廠 | 提供一個創建一系列相關或相互依賴對象的接口，而無需指定具體的類。 |
| Builder | 建造者模式 | 講一個複雜對象的構建和他的表示分離，使得同樣的構建過程可以創建不同的表示 |
| Prototype | 原型模式 | 用原型實例指定創建對象的種類，並且通過拷貝這個原型來創建新的對象。 |
結構型模式
關注類與對象之間的組合
| 模式名稱 | 中文名稱 | 基本定義 |
|---|---|---|
| Adapter | 適配器模式 | 將一個類的接口轉換成客戶希望的另一個接口。適配器使得原來不兼容的接口可以一起工作。 |
| Bridge | 橋接模式 | 將抽象部分與它的實現部分分離，使他們都可以獨立變化 |
| Composite | 組合模式 | 將對象組合成樹形結構以表示“部分-整體”的層次結構。組合模式使得客戶對單個對象對單個對象和複合對象的使用具有一致性。 |
| Decorator | 裝飾器模式 | 動態的給一個對象添加一些額外的職責。就擴展方式而言，裝飾器模式比生成子類的方式更靈活 |
| Facade | 外觀模式 | 爲子系統的一組接口提供一個一致的界面，Facade模式定義了一個高層的接口，這個接口使得這一個子系統更容易使用。 |
| Flyweight | 享元模式 | 運用共享技術有效的支持大量細粒度對象。 |
| Proxy | 代理模式 | 爲其他對象提供一個代理以控制對這個對象的訪問。 |
行爲型模式
關注對象和行爲的分離
| 模式名稱 | 中文名稱 | 基本定義 |
|---|---|---|
| Interpreter | 解釋器模式 | 給定一個語言，定義它的文法的一種表示，並定義一個解釋器，該解釋器使用該表示來解釋語言中的例子。 |
| Template Method | 模板方法模式 | 定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。模板方法使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟 |
| Chain of Responsibility | 職責鏈模式 | 爲解除請求的發送者和接收者之間的耦合，而使多個對象都有機會處理這個請求。講這些對象連着一個鏈，並沿着這條鏈傳遞該請求，直到一個對象處理它。 |
| Command | 命令模式 | 將一個請求封裝成一個對象，從而使你可用不同的請求對客戶進行參數化，對請求排隊或記錄請求日誌，以及支持可取消操作。 |
| Iterator | 迭代器模式 | 提供一種方法順序訪問一個聚合對象中的各個元素，而又不需要暴露該對象的內部表示。 |
| Mediator | 媒介模式 | 用一箇中介對象來封裝一系列的對象交互。中介者使各對象不需要顯示的相互引用，從而使其耦合鬆散，而且可以獨立地改變他們之間的交互。 |
| Memento | 備忘錄模式 | 在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在這個對象之外保存這個狀態。這樣就可以將這個對象恢復到保存的狀態。 |
| Observer | 觀察者模式 | 定義對象間的一種一對多的依賴關係，以便當一個對象的狀態發生改變時，所有依賴於它的對象都得到通知並自動刷新。 |
| State | 狀態模式 | 允許一個對象在其內部狀態改變時改變他的行爲。對象看起來似乎修改了他所屬的類。 |
| Strategy | 策略模式 | 定義一系列算法，把它們一個個封裝起來，並且使他們可相互替換，本模式使得算法的變化可獨立於他的客戶 |
| Visitor | 訪問者模式 | 表示一個作用於某對象結構的各元素的操作。他使你可以在不改變元素的類的前提下定義作用於這些元素的操作 |
三、設計模式六大原則詳細解析
- 單一職責：一個類只負責一 項職責
- 里氏替換原則：子類可以擴展父類的功能，但不能改變原有父類的功能。儘量用子類替換父類
- 依賴倒置原則：抽象不應該依賴於細節，細節應當依賴於抽象，面向接口編程
- 接口隔離原則：使用多個專門的接口，而不使用單一的總接口。即 客戶端不應該依賴於那些它不需要的接口
- 迪米特原則：最少知道原則，儘量降低類與類之間的耦合；一個對象應該對其他對象有最少的瞭解
- 開閉原則：對擴展開放，對修改關閉，能擴展不修改
