簡單明了的設計模式-立意篇
1.歲月的沉澱
我們為什麼要學設計模式？
如果是在我剛成為程式設計師的時候，我大概會這麼回答：
因為設計模式是前人經驗的總結，可以用來解決特定環境下，重複出現的特定問題。
同時也是程式設計師進階的必備知識。
上面的說法當然沒有錯，但是如果讓現在的我來回答，我會加上這幾句：
因為設計模式不會過時。
是的，在工作多年以後，看見各種技術如大浪淘沙一般從興起到衰落，看見主流技術棧兩三年就換血一次，我不禁陷入了深深的擔心：如果我學不動了怎麼辦？
特別是在年齡漸長之後，雖然大多數技術都有相通之處，想要快速掌握並不難。可是細微之處卻也有不少坑，真用起來，踩坑肯定也是少不了的。
所以漸漸的，我開始尋找那些不變的東西，尋找在這些讓人眼花繚亂的技術背後，在漫長歲月中真正能沉澱下來的東西。
不錯，我想你已經猜到了，就是那些老生常談的東西，大學時老師曾經無數次在我耳邊強調的東西：
數據結構、演算法、設計模式……
最質樸的東西往往最珍貴，古人誠不欺我，哈哈。
作為一名普通的碼農，數據結構和演算法平時接觸不多，真正用的多的，還是設計模式。
-
設計一個功能模組要用到設計模式，否則根本沒法維護
-
扒開源項目的源碼要懂設計模式，否則有可能看不懂
-
程式碼review也會用到，雖然不直接用模式，但是會用到原則
所以，對我而言，設計模式已經成為擋在身前的一座山，要麼跨過去，要麼永遠止步於此。
所以有了簡明設計模式的寫作計劃，願我們都能征服這座大山，最後同立山巔，看日升日落，雲捲雲舒。
2.設計模式的分類
設計模式一共23個。
其實設計模式之間也有很多共性和差異，為了方便理解和記憶，一般來說會分為三類：
-
創建型模式：抽象了對象實例化過程，用來幫助創建對象的實例
-
結構型模式：描述如何組合類和對象以獲得更大的結構
-
行為型模式：描述演算法和對象間職責的分配
具體情況如下圖：
3.磨一下刀
所謂磨刀不誤砍柴工，在學習設計模式之前，我們還需要掌握兩種武器：設計原則和UML類圖
學習UML類圖，是為了能夠更好的理解設計模式的結構
學習設計原則，則是為了知道設計模式為什麼要這麼設計
這個就放到下次說吧。
本文由部落格一文多發平台 OpenWrite 發布！
