GOF23種設計模式(Design Pattern)總結

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         沒有設計模式是萬能的,沉迷於得到一個解決方案的話可能會致使項目結構複雜、代碼可讀性差、而且形成項目延期

相關文章
相關標籤/搜索