前言
加入Design & Pattern團隊有幾個月的時間了，慚愧的是從沒有寫過關於設計模式的隨筆，得到wayfarer的同意，把企業庫系列的隨筆放在了團隊的首頁上。不是不想去寫這樣的隨筆，也不是沒有時間，自己初學設計模式，去寫設計模式的文章，有點班門弄斧的味道。園子裡呂震宇老師的《設計模式系列》和wayfarer的《設計之道》堪稱設計模式裡的經典之作。可是正如wafarer所說的那樣，受到發表欲的蠱惑，本著交流就是進步的想法，思考再三，還是決定寫這樣的隨筆，來對設計模式做一些探索和總結，起名曰“探索設計模式”，有些言過其實，就當是記錄自己學習設計模式的歷程吧，不過還是希望能得到各位前輩的指點！
設計模式
設計模式是規則嗎？
地上本沒有路，走得人多了也就成了路。設計模式如同此理，它是經驗的傳承，並非體系；是被前人發現，經過總結形成了一套某一類問題的一般性解決方案，而不是被設計出來的定性規則；它不像算法那樣可以照搬照用。
設計模式是架構嗎？
架構和模式應該是一個屬於相互涵蓋的過程，但是總體來說架構更加關注的是所謂的High-Level Design,而模式關注的重點在於通過經驗提取的“准則或指導方案”在設計中的應用，因此在不同層面考慮問題的時候就形成了不同問題域上的模式。模式的目標是，把共通問題中的不變部分和變化部分分離出來。不變的部分，就構成了模式，因此，模式是一個經驗提取的“准則”，並且在一次一次的實踐中得到驗證，在不同的層次有不同的模式，小到語言實現，大到架構。在不同的層面上，模式提供不同層面的指導。
設計模式，軟件的永恆之道？
這個問題沒有答案，有的只是討論，看一下一位前輩結合建築學得出的幾點心得吧：
和建築結構一樣，軟件中亦有諸多的“內力”。和建築設計一樣，軟件設計也應該努力疏解系統中的內力，使系統趨於穩定、有生氣。一切的軟件設計都應該由此出發。
任何系統都需要有變化，任何系統都會走向死亡。作為設計者，應該擁抱變化、利用變化，而不是逃避變化。
好的軟件只能“產生”而不能“創造”，我們所能做的只是用一個相對好的過程，盡量使軟件朝向好的方向發展。
需要設計模式嗎？
答案是肯定的，但你需要確定的是模式的應用是否過度？我得承認，世界上有很多天才的程序員，他可以在一段代碼中包含6 種設計模式，也可以不用模式而把設計做得很好。但我們的目標是追求有效的設計，而設計模式可以為這個目標提供某種參考模型、設計方法。
我們不需要奉GOF的設計模式為圭臬，但合理的運用設計模式，才是正確的抉擇。很多人看過GOF的《Design Patterns》，對這23 種模式也背得滾瓜爛熟。但重要的不是你熟記了多少個模式的名稱，關鍵還在於付諸實踐的運用。為了有效地設計，而去熟悉某種模式所花費的代價是值得的，因為很快你會在設計中發現這種模式真的很好，很多時候它令得你的設計更加簡單了。
其實在軟件設計人員中，唾棄設計模式的可能很少，盲目誇大設計模式功用的反而更多。言必談“模式”，並不能使你成為優秀的架構師。真正出色的設計師，懂得判斷運用模式的時機。還有一個問題是，很多才踏入軟件設計領域的人員，往往對設計模式很困惑。對於他們來說，由於沒有項目的實際經驗，OO 的思想也還未曾建立，設計模式未免過於高深了。其實，即使是非常有經驗的程序員，也不敢誇口對各種模式都能合理應用。[--摘自wayfare的設計之道]
後記
關於設計模式的理論性的文章，已經寫了很多了，我不想再繼續重復抄寫下去，僅記錄下上面幾段話，用它來作探索設計模式系列的一個開篇吧。[現已更名為.NET設計模式]
