- 設計模式心得體會 推薦度：
- 相關推薦
設計模式心得體會
7月初的一個周末，準確的說應該是7月1號周六，在網上看到一本《大話設計模式》的書，而且看到很多很好的評論，于是乎，下載了電子書看看，一下子看了幾章之后，對設計模式有了個了解，于是繼續上網搜些其他資料，進一步了解設計模式。。。最終結論：設計模式是個好東西，具體怎么好，一兩句話是無法概括的，也是從那天起，我就決定學習設計模式，于是就看《大話設計模式》，至七月十多號，大概看了一百多頁后，感覺有點難，有點看不下去的感覺，于是上網找其他的好方法，無意間發現了李建忠老師的《C#設計模式縱橫談》系列講座，微軟的Web Cast課程，主要講解GOF的23個設計模式，每個一講，加上一頭一尾，共25講，試聽了一節課后，感覺很有用，于是就抽時間去邊聽課邊看書，并在我的博客里寫下筆記，依賴加深印象，二來可以督促我的進度。。。三個月以來，總算把設計模式學完一遍了，原計劃是兩個月學完（一星期三個模式），由于。。。計劃兩個月學完實際花了三個月，感觸多多，收獲多多——對C#語言有了更進一步的認識，對OO的思想有了更全面的了解。。。
下一步在設計模式方面的計劃：鞏固并運用設計模式，鞏固：把《大話設計模式》，《設計模式》，《設計模式——可復用的面向對象基礎》，《敏捷軟件開發：原則、模式與實踐》這些書再結合起來系統的看一看，當然還會去買一些我手頭上沒有的關于設計模式的書；運用：部門前幾天也提倡用C#來改版VB程序，我想這是一個很好的平臺，正好有機會把理論的東西在實際中應用，理論加實際——唯一的學習方法。。。
下面對各個模式再簡單總結一下：
1、創建型模式：
Singleton：解決的是實例化對象的個數的問題，比如抽象工廠中的工廠、對象池等，除了Singleton之外，其他創建型模式解決的都是 new 所帶來的耦合關系。
Abstract Factory：創建一系列相互依賴對象，并能在運行時改變系列。
Factory Method：創建單個對象，在Abstract Factory有使用到。
Prototype：通過拷貝原型來創建新的對象。
Factory Method，Abstract Factory, Builder都需要一個額外的工廠類來負責實例化“一邊對象”，而Prototype則是通過原型（一個特殊的工廠類）來克隆“易變對象”。
如果遇到“易變類”，起初的設計通常從Factory Method開始，當遇到更多的復雜變化時，再考慮重構為其他三種工廠模式（Factory Method，Abstract Factory, Builder）。
2、結構性模式
Adapter：注重轉換接口，將不吻合的接口適配對象，用于舊代碼復用、類庫遷移等。
Bridge：注重實現抽象和實現的分離，支持對象多維度的變化。
Composite：注重同意接口，將“一對多”的關系轉化為“一對一”的關系，屏蔽對象容器內部實現結構，實現對象和對象容器使用的一致性。
Decorator：注重穩定接口，在此前提下為對象擴展功能，實現對象功能的擴展，避免子類膨脹。
Facade：注重簡化接口，屏蔽各子系統的復雜性，提供更高層接口供客戶訪問。
Flyweight：注重保留接口，在內部使用共享技術對對象存儲進行優化（通過共享大量細粒度對象，提供系統性能）。
Proxy：注重假借接口，通過增加間接代理，實現更多控制，屏蔽復雜性。
3 、行為型模式
Template Method：封裝算法結構，定義算法骨架，支持算法子步驟變化。
Strategy：注重封裝算法，支持算法的變化，通過封裝一系列算法，從而可以隨時獨立于客戶替換算法。
State：注重封裝與狀態相關的行為，支持狀態的變化，通過封裝對象狀態，從而在其內部狀態改變時改變它的行為。
Memento：注重封裝對象狀態變化，支持狀態保存、恢復。
Mediator：注重封裝對象間的交互，通過封裝一系列對象之間的復雜交互，使他們不需要顯式相互引用，實現解耦。
Chain of Responsibility：注重封裝對象責任，支持責任的變化，通過動態構建職責鏈，實現事務處理。
Command：注重將請求封裝為對象，支持請求的變化，通過將一組行為抽象為對象，實現行為請求者和行為實現者之間的解耦。
Iterator：注重封裝特定領域變化，支持集合的變化，屏蔽集合對象內部復雜結構，提供客戶程序對它的透明遍歷。
Interpreter：注重封裝特定領域變化，支持領域問題的頻繁變化，將特定領域的問題表達為某種語法規則下的句子，然后構建一個解釋器來解釋這樣的句子，從而達到解決問題的目的。
Observer：注重封裝對象通知，支持通信對象的變化，實現對象狀態改變，通知依賴它的對象并更新。
Visitor：注重封裝對象操作變化，支持在運行時為類結構添加新的操作，在類層次結構中，在不改變各類的前提下定義作用于這些類實例的新的操作。
正確對待模式：
設計模式建立在對系統變化點的基礎上進行，哪里有變化，哪里就應用設計模式。
設計模式應該以演化的方式來獲得，系統的變化點往往是經過不斷演化才能準確定位。
不能為了模式而模式，設計模式是一種軟件設計的軟力量，而非規范標準，不應夸大設計模式的作用。
------------------
從一開始學習設計模式至今已半年有余了，第一次接觸設計模式是一次不經意間在網上看到《大話設計模式》一書，看了前言了第一章后，就感覺到其誘惑力對于一個程序員來說，是無比巨大的。大概是去年十月份的時候，部門決定成立讀書會，系統學習設計模式。
通過學習設計模式，除了學習到“一些設計模式”，還讓我進一步熟悉、鞏固了面向對象思想，進一步熟悉了C#語言。。。我曾多次設想，我們如果引入面向對象思想，并結合設計模式來重寫或改善我們的系統（必須重寫，雖說設計模式只是一種思想，語言只是實現而已，但是選擇一門好的語言，無疑也是非常重要的，而VB6在面向對象方面卻有很大欠缺甚至不具備其條件），那么我們的系統將會像目前一樣需要那么多人來維護嗎？
《大話設計模式》一書其實是對GOF的《設計模式——可復用面向對象軟件的基礎》一書的“翻譯”，讓人更容易理解，用通俗易懂的語言闡述軟件設計過程中的一些“模式”，在某種特定環境下，用最好的設計方法（代碼高內聚，低耦合，使其有良好的可擴展性和可維護性）達到我們的目的，或許其方法有很多很多，但是尋找到最好的方法卻不是件容易的事，設計模式是對前人的設計經驗的一個總結，告訴我們在某種特定的環境下，這樣的設計師最好的，學習設計模式有助于我們在設計軟件的過程中少走很多彎路。
我對GOF的23個設計模式雖然都有看過，但是只有理解，實現，應用及思考之后，才能真正體會其精妙之處，至今體會較深的有以下幾個模式：1. Strategy——封裝系列“算法”，讓它們之間可以相互替換，“算法”并不是單指數據結構中的算法，在實踐中，它幾乎可以封裝任何類型的規則，這使得策略模式的運用極其廣泛；2. Template Method——有人說是用的做多的模式，只要有抽象類的地方，都可以看到這個模式，它通過把不變行為移到父類中去，去除子類中的重復代碼，從而提供了一個很好的代碼復用平臺；3. Facade——提供了對基礎架構的統一訪問，減少復雜性，在Web編程者中的三層架構，就是此思想，每一層都封裝好一部分功能，提供給上一層統一的方法調用，整個Framework體系就是Facade模式的封裝，隨著1.0升級到3.5，越來越多復雜的高級功能被封裝，可以說Facade無處不在；4. Abstract Factory——提供一個創建一系列相關或相互依賴對象的接口，而無需指定它們具體的類，咋一看，太抽象了，說個例子，在三層架構中，BLL層對DAL層的調用會直接用到DAL層中的類，如果DAL層是分別對SQL Server，Oracle的訪問，BLL層需要根據實際情況決定實例化哪一個DAL層中的類，我們又希望在兩種DAL層切換時，BLL層和UI層都不做改變，那么可在BLL層和DAL層中增加接口層（體現了“抽象”的精神，或者說是“面向接口編程”的最佳體現）和抽象工廠（DALFactroy），讓它來實例化DAL層中的實例；5. Singleton——確保一個類僅有一個實例，并提供一個訪問它的全局訪問點，如單件窗體，點一下Menu，彈出一個窗體(實例)，在關閉這個新窗體之前，再次點擊該Menu，不會再次出現同樣的彈出窗體(實例)。。。篇幅有限，其他模式或多或少都有點感覺。
最后，引用《設計模式解析》書中的一句話：設計模式體現的是一種思想，而思想是指導行為的一切，理解和掌握了設計模式，并不是說記住了23種（或更多）設計場景和解決策略（實際上這也是很重要的一筆財富），實際接受的是一種思想的熏陶和洗禮，等這種思想融入到了你的思想中后，你就會不自覺地使用這種思想去進行你的設計和開發，這一切才是最重要的。
【設計模式心得體會】相關文章：
設計模式心得體會（通用17篇）05-25
關于教學設計模式的探討04-30
軟件體系結構與設計模式課程教學模式的探討04-28
淺析設計素描課程的訓練模式04-28
MVC設計模式在ASPNET中的實現05-02
淺議音樂教學模式的設計與實踐04-28
氣體制備設計模式論文05-04
故障模式下的空間交會防撞設計04-27
向數字化設計模式轉變04-28