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：注重封裝對象操作變化，支持在運行時為類結構添加新的操作，在類層次結構中，在不改變各類的前提下定義作用於這些類實例的新的操作。
正確對待模式：
設計模式建立在對系統變化點的基礎上進行，哪裏有變化，哪裏就應用設計模式。
設計模式應該以演化的方式來獲得，系統的變化點往往是經過不斷演化才能準確定位。
不能為了模式而模式，設計模式是一種軟件設計的軟力量，而非規範標準，不應誇大設計模式的作用。
設計模式心得體會（2）：
從一開始學習設計模式至今已半年有餘了，第一次接觸設計模式是一次不經意間在網上看到《大話設計模式》一書，看了前言了第一章後，就感覺到其誘惑力對於一個程序員來説，是無比巨大的。大概是去年十月份的時候，部門決定成立讀書會，系統學習設計模式。
通過學習設計模式，除了學習到“一些設計模式”，還讓我進一步熟悉、鞏固了面向對象思想，進一步熟悉了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種（或更多）設計場景和解決策略（實際上這也是很重要的一筆財富），實際接受的是一種思想的薰陶和洗禮，等這種思想融入到了你的思想中後，你就會不自覺地使用這種思想去進行你的設計和開發，這一切才是最重要的。