今天在SD2大會上，聽了李建忠老師講的《.NET框架中的幾個典型設計模式》課程收益非淺，李建忠老師的課總能給人醍醐灌頂的感覺，去年的《WPF核心機制》讓我們可以從根本上理解WPF的革命。今年的設計模式，也是從根本上理解設計模式產生的原因，適用的場景。

       下面是我對課程整理的一些筆記和心得，跟大家分享：

       軟體的需求一直在變化。很變態，但是很多人都碰到過的情況：一直到程式碼編寫完畢前，需求都可能在變化，需求的凍結要到編碼完畢時才完成。
       為此，軟體的開發方法從最初的瀑布開發， 到迭代開發再到敏捷開發。他們都是適應軟體的需求、設計遲遲不能凍結定稿的產物。上面提到的開發方法，一個比一個需求、設計定稿的時間要晚。
       當然，變化不能一直不穩定，那麼我們軟體就永遠不能釋出了。

       軟體的架構也受到這些影響：
       我們預計到會變的因素我們會寫在配置檔案ini或者XML配置檔案中。
       甚至我們預計要變得東西單單配置檔案都不可以搞定了，我們要把這些預計要變的東西寫成解析執行的指令碼語言。今天早上蔡學鏞講的《Scriptable Software與DSL的設計》，下午周愛民講的《JavaScript + Delphi + ErLang = ？》從這裡提到的變化角度來說，都是為了適應這種變化對架構的影響採用的方法。
       [魔獸世界]編寫外掛用的LUA語言，[文明4]用的Python語言...都是這方面的典範。

       對於設計模式，也同樣的是受變化影響的。
       我們預計到一個地方是穩定的，就一個選擇，我們如果還用設計模式，就是愚蠢的效能低下的做法。設計模式應該用到我們預計到這裡會發生變化，為了保證複用性，我們對變化進行抽象，抽象出一個穩定的抽象。抽象出來的這個類，如果時不時都會變化一下，那簡直要瘋了，這個抽象的類一定要保證穩定性。這才是OO思想,設計模式的思想.
       應對變化，提高複用，這是OO設計的基本原則,也是設計模式的基本原則。
       晚繫結機制就是對這些變化的支援。.NET的晚繫結有四種方法：虛擬函式，委託（函式指標），反射，範型。對應的23種設計模式都是用這些來實現的。 
       MSDN的WebCast中，李建忠老師對C#設計模式有25節課的講座，詳細介紹了23種設計模式。在下面地址可以看到，下載：

       這些年的開發經驗積累下來，我發現我的設計、架構很多時候都是一個四不象，或者是一個性能，可擴充套件性等中庸折中的取捨方案。一定要想清楚哪些是要變化的，不會變化的，不要畫蛇添足的裝酷。對於要變化的要做到應對變化，提高複用來抽象，高水平的技術人員，抽象出來的東西不會三天兩頭就變的。