（原創）無廢話C#設計模式之一：開篇

 

無廢話C#設計模式之一：開篇

 

什麼是設計模式？

 

       什麼是少林拳呢？少林拳是少林僧人經過長期的總結，得出的一套武功套路。有一本叫做少林拳法的武功秘籍，上面記載這這套拳法的適用人群，打法套路和學成後的效果。設計模式雖然記錄在了設計模式一書上，但是要真正掌握設計模式光靠看每一個模式的結構並且進行模仿是不夠的。試想一下，在真槍實戰的情況下，誰會和你按照少林拳法，一二三四的套路打呢？打套路也只能用來看看，只有當你能根據不同的情境靈活出招的時候才能說是學會了這套拳法。相似的例子還有三十六計，這也是一種模式，每種計謀都是針對不同情境的，如果不管遇到什麼時候都來個“走為上”，那這仗還怎麼打呢？

       總之，設計模式要用活才能發揮作用。

 

設計模式有什麼用？

 

       設計模式可以讓你在遇到需求變化的時候不至於手忙腳亂。設計模式可以讓你程式的可維護性、可擴充性更好。設計模式可以讓程式的效能更高。當然，這些的前提是正確使用了設計模式，如果濫用的話那麼設計模式可以讓程式沒人看得懂，讓程式速度慢到死，讓程式不能維護，添加新的功能等於重做。

 

設計模式的原則？

 

l         單一職責：你不希望因為電腦記憶體損壞而更換CPU吧，同樣也不應該讓一個類有多種修改的理由。

l         對擴充開放，對修改封閉：你一定不希望電腦只有一個記憶體槽，加記憶體就要換主板吧，程式也應該能在不修改原先程式的情況下就能擴充功能。

l         裡氏替換：如果你買的DX9顯卡不支援DX9特性，那麼這個顯卡一定沒法用。如果父類的方法在子類中沒有實現那就暈了。在程式的世界中千萬別認為鳥都會飛，先考慮清楚將會有哪些鳥吧。

l         依賴倒置：針對介面編程，這樣即使實現有變也不需要修改外部代碼。其實，現在電腦的硬體、網路通訊等都是符合這個原則的，比如USB介面、PCI-E介面、TCP/IP協議。

l         介面隔離：花3000買一個帶拍照、聽MP3功能的手機還是花1000買一個手機、1000買一個MP3、1000買一個數位相機呢？買了前者的話手機動不動就要修，而且還不一定是因為不能打電話而修，買了後面三樣的話即使修也不影響其它使用，你說買哪個？

記得看過一個例子很恰當，說是修電腦比修收音機簡單多了。電腦壞了，更換一個零件即可，原因是電腦中的各部分都是基於相對穩定的介面，而且組件各司其職，不會相互影響，電腦本身就是一個非常符合設計原則的產品。收音機的修理沒有這麼簡單了，沒有什麼組件是外掛程式式的，會修收音機的人肯定明白其中每一個組件的原理。

小程式就好像收音機，確實可以這麼做，一共才一個人做的，即使重新做也用不了多少時間。幾十個人的大項目如果要改一個需求需要牽涉所有人來修改，那麼這個項目用不了多少時間就會因為維護成本太大，維護後BUG太多而報廢。

 

怎樣學習設計模式？

 

       學習新概念英文要什麼基礎？首先，要知道26個字母吧。如果你對物件導向完全沒有概念的話，建議先可以看一下物件導向的一些知識。畢竟，設計模式是物件導向編程模式的一種總結。學了26個字母你就可以學習新概念了，但是，為了能更好地學習最好是先學一下國際音標。對於設計模式的學習來說，你可以學習一下UML的一些知識。當然，完全不知道UML也可以學習設計模式，在學習的過程中慢慢也就會UML了。

設計模式不是什麼很高深的東西，有了這些知識大膽地學習吧。很多人說，看了很多設計模式的文章，為什麼就是看不懂呢？我覺得原因可能有兩個，第一就是你沒有花時間認真看，第二就是看的文章不適合作為切入點。不管學習什麼，切入點非常重要，如果切入點不是那麼平易近人的話很可能會把你拒之門外，對於初學者來說從執行個體切入最合適。最好是能碰到自己做過的項目的執行個體作為切入點，這樣你一比較就知道為什麼設計模式好了。

如果要把設計模式的學習境界分一下級的話，我這麼分：

l         第一重：能看懂設計模式的文章

l         第二重：能自己寫一個設計模式的骨架

l         第三重：能自己編一個新的運用設計模式的例子

l         第四重：能在寫代碼的時候想到似乎有設計模式適合，在翻閱資料後找到了這種設計模式

l         第五重：在理解項目的需求後就能意識到哪裡可以使用哪種設計模式進行最佳化

l         第六重：完全掌握了設計模式的精髓，靈活使用各種設計模式以及其變種

不管怎麼樣，多看多做多替換才是學習的辦法，別人舉例十個都不及自己做一個例子，被動十個原則都不及自己體會出一個原則。每一種設計模式雖然都有一個骨架，但是也不必過於強調這個形式，很多時候根據自己的需求簡化一點，改變一點，或者混雜一些其它的設計模式，只要能實現目的了，也是一個不錯的選擇。

很多人會覺得這麼多種設計模式沒有幾種能用得上。我覺得這不是什麼問題，用不上那就用不上，這些設計模式是大師經曆無數大型項目後的精華，如果能在自己做的一個小項目中用上兩三個就很不錯了，用上二三十個的項目絕對是怪胎。用不上千萬彆強求，否則既不利於項目的可維護性又增加了工作量。

還有很多人會覺得這些設計模式很多都是相似的。而且每個人的感覺還不一樣，有人覺得A和B很相似，有人卻覺得A和B很好區分，但是B和C卻很相似啊。感覺很好區分，說明你看準設計模式的著重點的，感覺一樣說明你看到的還是它的形。雙胞胎雖然形一樣，但是神肯定不一樣的，只要認準設計模式解決的問題，就不會看錯。

 

關於本系列文章

 

  

       本來這些內容都是用來進行公司內部每周知識分享活動的，既然有一些內容了，想想不妨就整理一下貼出來吧。也正由於這個原因，文章中的一些例子都基於團隊內部成員所能理解的一些項目，可能這些項目對大家來說比較陌生，不過好處是例子相對比較貼近實際一點。本系列一共有20篇左右，除了介紹23種GOF設計模式中常用的一部分之外（一些設計模式的思想在C#語言中有了更簡單的實現，一些設計模式不是很常用）還可能會介紹一些其它有用的設計模式。在這些文章中，我不會過多去說一些理論上的東西，也不會有結構圖（這些內容網上到處都是），所有的內容都是圍繞相對實際例子展開。我想，只有這樣才能更快的吸收設計模式的神而不是其形。在看文章的時候建議你結合《設計模式》一書以及部落格園的其它設計模式相關文章一起看，這樣才能對設計模式理解的全面和充分一點。

       每一篇文章都會有以下部分：

l         意圖：抄設計模式一書的，因為意圖實在是太重要，所以不得不首先列出。

l         情境：以一個實際的情境來說明為什麼要引入設計模式。

l         範例程式碼：對引入設計模式後情境的說明。

l         代碼說明：說明設計模式中的幾個角色以及代碼中需要注意的地方。

l         何時採用：從代碼和應用兩個角度說明何時採用這個模式。

l         實現要點：實現這種模式必要的幾個地方，或者說模式主要的特點在哪裡。

l         注意事項：模式的優點缺點以及什麼時候不應該使用設計模式。

【注】由於本系列文章發布周期不定，內容簡短，並且不是非常完整，發布的新文章不會在首頁出現，感興趣的，請關注BLOG。

查看所有文章請點擊 （原創）無廢話C#設計模式系列文章