程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> .NET網頁編程 >> C# >> 關於C# >> 無廢話C#設計模式之二十二:總結(針對GOF23)

無廢話C#設計模式之二十二:總結(針對GOF23)

編輯:關於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 一般 應用級 設計時 比較復雜

注:常用程度、適用層次、使用時機等基於自己的理解,結構復雜度基於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 沒有設計模式是萬能的,沉迷於獲得一個解決方案的話可能會導致項目結構復雜、代碼可讀性差、並且造成項目延期

結束語

l 常用的GOF 23種設計模式介紹完了,這才是起點。

l 本系列文章並沒有結束,關注之後非GOF 23種設計模式的相關文章。

l 如果適當運用C# 2.0一些有用的特性(特別是代理、泛型以及分部類和設計模式關聯比較大)的話,傳統的設計模式有非常大的改進的余地。在實際運用的過程中,優先考慮適用語言特性,如果不行再去考慮適用設計模式。

l 迭代器模式(在C# 2.0中實現非常簡單)、解釋器模式(應用面非常小,自己也沒有整明白)以及備忘錄模式(比較簡單,沒有什麼可說的)沒有單獨立文介紹,但在代碼包中包含了相應的例子。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved