GOF23種設計模式(Design Pattern)總結 算法
設計模式設計模式 |
經常使用程度學習 |
適用層次優化 |
引入時機ui |
結構複雜度編碼 |
Abstract Factoryspa |
比較經常使用設計 |
應用級server |
設計時對象 |
比較複雜 |
Builder |
通常 |
代碼級 |
編碼時 |
通常 |
Factory Method |
很經常使用 |
代碼級 |
編碼時 |
簡單 |
Prototype |
不太經常使用 |
應用級 |
編碼時、重構時 |
比較簡單 |
Singleton |
很經常使用 |
代碼級、應用級 |
設計時、編碼時 |
簡單 |
Adapter |
通常 |
代碼級 |
重構時 |
通常 |
Bridge |
通常 |
代碼級 |
設計時、編碼時 |
通常 |
Composite |
比較經常使用 |
代碼級 |
編碼時、重構時 |
比較複雜 |
Decorator |
通常 |
代碼級 |
重構時 |
比較複雜 |
Facade |
很經常使用 |
應用級、構架級 |
設計時、編碼時 |
簡單 |
Flyweight |
不太經常使用 |
代碼級、應用級 |
設計時 |
通常 |
Proxy |
比較經常使用 |
應用級、構架級 |
設計時、編碼時 |
簡單 |
Chain of Resp. |
不太經常使用 |
應用級、構架級 |
設計時、編碼時 |
比較複雜 |
Command |
比較經常使用 |
應用級 |
設計時、編碼時 |
比較簡單 |
Interpreter |
不太經常使用 |
應用級 |
設計時 |
比較複雜 |
Iterator |
通常 |
代碼級、應用級 |
編碼時、重構時 |
比較簡單 |
Mediator |
通常 |
應用級、構架級 |
編碼時、重構時 |
通常 |
Memento |
通常 |
代碼級 |
編碼時 |
比較簡單 |
Observer |
比較經常使用 |
應用級、構架級 |
設計時、編碼時 |
比較簡單 |
State |
通常 |
應用級 |
設計時、編碼時 |
通常 |
Strategy |
比較經常使用 |
應用級 |
設計時 |
通常 |
Template Method |
很經常使用 |
代碼級 |
編碼時、重構時 |
簡單 |
Visitor |
通常 |
應用級 |
設計時 |
比較複雜 |
注:經常使用程度、適用層次、使用時機等基於本身的理解,結構複雜度基於C#語言,表格中全部內容僅供
原則、變化與實現
設計模式 |
變化 |
實現 |
體現的原則 |
Abstract Factory |
產品家族的擴展 |
封裝產品族系列內容的建立 |
開閉原則 |
Builder |
對象組建的變化 |
封裝對象的組建過程 |
開閉原則 |
Factory Method |
子類的實例化 |
對象的建立工做延遲到子類 |
開閉原則 |
Prototype |
實例化的類 |
封裝對原型的拷貝 |
依賴倒置原則 |
Singleton |
惟一實例 |
封裝對象產生的個數 |
|
Adapter |
對象接口的變化 |
接口的轉換 |
|
Bridge |
對象的多維度變化 |
分離接口以及實現 |
開閉原則 |
Composite |
複雜對象接口的統一 |
統一複雜對象的接口 |
里氏代換原則 |
Decorator |
對象的組合職責 |
在穩定接口上擴展 |
開閉原則 |
Facade |
子系統的高層接口 |
封裝子系統 |
開閉原則 |
Flyweight |
系統開銷的優化 |
封裝對象的獲取 |
|
Proxy |
對象訪問的變化 |
封裝對象的訪問過程 |
里氏代換原則 |
Chain of Resp. |
對象的請求過程 |
封裝對象的責任範圍 |
|
Command |
請求的變化 |
封裝行爲對對象 |
開閉原則 |
Interpreter |
領域問題的變化 |
封裝特定領域的變化 |
|
Iterator |
對象內部集合的變化 |
封裝對象內部集合的使用 |
單一職責原則 |
Mediator |
對象交互的變化 |
封裝對象間的交互 |
開閉原則 |
Memento |
狀態的輔助保存 |
封裝對象狀態的變化 |
接口隔離原則 |
Observer |
通信對象的變化 |
封裝對象通知 |
開閉原則 |
State |
對象狀態的變化 |
封裝與狀態相關的行爲 |
單一職責原則 |
Strategy |
算法的變化 |
封裝算法 |
里氏代換原則 |
Template Method |
算法子步驟的變化 |
封裝算法結構 |
依賴倒置原則 |
Visitor |
對象操做變化 |
封裝對象操做變化 |
開閉原則 |
學習
l 掌握設計模式的意圖以及解決的問題
l 掌握設計模式所封裝的變化點以及優缺點
l 瞭解設計模式的結構圖以及各角色的職責
l 項目中是否應用了設計模式不重要,重要的是設計模式是否正確應用
l 項目中應用的設計模式和GOF設計模式的結構是否一致不重要,重要的是是否從這個結構中得意
l 無論用了仍是沒有用設計模式,若是違背了原則,就是不恰當的設計
l 沒有設計模式是萬能的,沉迷於得到一個解決方案的話可能會致使項目結構複雜、代碼可讀性差、而且形成項目延期