設計模式 設計模式這一概念最早起源於建築領域，是Christopher Alexander在其著作《建築模式語言》中首次提及， 而後經過歲月的洗禮與沉澱，由我們的前輩們引入到軟體設計領域, 其作為一種設計問題的思想，經過眾多軟體開發前輩們經過反覆的實踐和踩坑之後得到的經驗，逐漸趨於成熟和完善。應用這 ...
設計模式
設計模式這一概念最早起源於建築領域，是Christopher Alexander在其著作《建築模式語言》中首次提及， 而後經過歲月的洗禮與沉澱，由我們的前輩們引入到軟體設計領域, 其作為一種設計問題的思想，經過眾多軟體開發前輩們經過反覆的實踐和踩坑之後得到的經驗，逐漸趨於成熟和完善。應用這種經驗可以試我們的代碼更加規範， 重用度更高，增加了代碼的可讀性，可靠性和魯棒性 。便於更好的開發和維護。學習這些模式也可以有助於開發經驗不足的開發人員用一種跟簡單快捷的方式來設計軟體。其核心偏向與設計問題，這是與演算法存在不同的地方， 演算法核心是解決問題。
設計模式可歸納為創建型，行為型和結構型設計模式
下麵列出了常見的設計模式以及所屬分類，後面會持續更新相關模式的詳細文章
| 類別 | 描述 | 包含設計模式 |
| 創建型 | 這種模式提供了一種在創建對象的同時隱藏了對象創建邏輯的方式， 而不是通過簡單的new運算符直接實例化對象，使程式在判斷針對某個指定的實例需要創建哪些對象更加靈活 |
簡單工廠模式（Simple Factory Pattern） 工廠模式（Factory Pattern） 抽象工廠模式（Abstract Factory Pattern） 單例模式（Single Factory Pattern） 建造者模式（Builder Pattern） 原型模式（Prototype Pattern） |
| 行為型 | 這種模式是為了滿足特定行為而設計的解決方案，關註類和對象的組合 |
適配器模式（Adaptor Pattern） 橋接模式（Bridge Pattern） 過濾器模式（Filter Pattern） 組合模式（Composite Pattern） 裝飾器模式（Decorator Pattern） 外觀模式（Facade Pattern） 享元模式（Flyweight Pattern） 代理模式（Proxy Pattern） |
| 結構型 | 這種模式是從結構上解決程式的耦合問題，描述了類和對象之間的通信 |
責任鏈模式（Chain of responsibility Pattern） 命令模式（Command Pattern） 解釋器模式（Interpreter Pattern） 迭代器模式（Iterator Pattern） 中介者模式（Mediator Pattern） 備忘錄模式（Memento Pattern） 觀察者模式（Observer Pattern） 狀態模式（State Pattern） 空對象模式（Null Object Pattern） 策略模式（Strategy Pattern） 模板模式（Template Pattern） 訪問者模式（Visitor Pattern） |
設計模式之六大原則
| 名稱 | 描述 |
| 單一職責原則 | Single Responsibility Principle, 簡稱SRP. 每個類應該實現單一職責, 換句話說就是有且僅有一個原因引起類的變更 |
| 里氏替換原則 |
為良好的定義繼承定義了一個規範 1. 子類必須完全實現父類的方法 2. 子類可以有自己的特性 3. 覆蓋或實現父類的方法時, 輸入參數可以被放大 4. 覆蓋或實現父類的方法時,輸出結果可以被縮小 |
| 依賴倒置原則 |
Dependency Inversion Principle, DIP. 是面向介面編程的設計原則 1. 高層模塊不應依賴低層模塊 2. 抽象不應該依賴細節, 細節應該依賴抽象. 具體表現就是抽象類或介面不應依賴實現類, 實現類應依賴介面或抽象類 三種寫法 1. 構造函數依賴 2. 定義抽象方法構造依賴對象 3. 介面聲明依賴對象 |
| 介面隔離原則 |
它所描述的類間的依賴關係應該建立在最小的介面上, 客戶端不應該依賴它不需要的介面 要求介面滿足以下規範 1. 介面儘量小. 介面應儘量細粒度設計, 增加介面靈活性 2. 介面要高內聚. 就是提高介面, 類, 模塊的處理能力. 儘量少的減少對外交互 3. 定製服務. 介面可以為客戶端單獨定製服務. 可以為不同的客戶提供不同的介面. 比如說, 一個介面只想給內部人員使用, 對外部隱藏, 那就需要定製服務了 4. 保持有限的介面設計. 介面設計靈活可能帶來結構的複雜化, 增加開發和維護難度 |
| 迪米特法則 | Law of Demeter, Lod 也叫最少知識原則. 描述的是一個對象應該對自己需要調用的對象類知道的最少. 只需要關心調用, 不需要關心實現 |
| 開閉原則 | 廣義的解釋就是對擴展開放, 對修改關閉. 這是一個樂觀的原則, 積極的擁抱變化, 假設變化必然發生, 應儘量通過擴展軟體的行為去實現這些變化, 而不是通過修改已有的代碼來完成變化. 一般是通過新增子類等方式覆蓋父類方法來實現擴展 |
設計模式存在的六種關係
| 關係名稱 | UML符號標識 | 描述 |
| 泛化關係 | 帶三角箭頭的實線，箭頭指向父類 | 屬於類的繼承關係，指明子類如何特化父類的所有特征和行為 |
| 依賴關係 | 帶箭頭的虛線，箭頭指向獨立的類 | 描述的是類的使用存在依賴關係，也叫使用關係（USE-A），表示兩個活動中一個活動的變更會影響另一個活動。例如一個類用另一個類作為其數據成員，一個類向另一個類發消息等 |
| 實現關係 | 帶三角箭頭的虛線，箭頭指向介面 | 描述了類是介面的全部實現 |
| 組合關係 | 帶實心菱形的實線，菱形指向整體，箭頭指向部分 | 描述的是整體與部分的關係，部分不能離開整體而單獨存在。例如公司和部門，部門不能離開公司而單獨存在，是關聯關係的一種 |
| 關聯關係 | 帶普通箭頭的實線，箭頭指向被關聯者 | 描述的是兩個類元之間的關係，例如類指向用例，水指向氣候，學生指向課程等 |
| 聚合關係 | 帶空心菱形的實心線，菱形指向整體，箭頭指向部分 | 描述的整體與部分的關係，部分能離開整體而單獨存在。例如自行車和車座，電腦和顯示器等 |
強弱順序：泛化 > 實現 > 組合 > 聚合 > 關聯 > 依賴
