爲何學了那麼屢次設計模式，仍是沒學會

這是我參與新手入門的第2篇文章

我相信不少人學習設計模式的經歷是這樣的：

1. 在學校老師跟你說，不只要學習框架，設計模式也很是重要。你開始瞭解學習設計模式，閱讀經典的《Head First 設計模式》，這時候你會感嘆設計模式的奇妙。

2. 開始找工做了，你知道面試可能會問到設計模式相關的問題，你又再次投入精力學習設計模式，但此次你是抱着速成的心態在學習。

3. 工做中，遇到複雜的業務場景，按照本身的想法寫業務代碼，你發現代碼並無那麼優雅，擴展性不強，耦合嚴重，每次業務擴展，你都須要當心翼翼維護舊代碼。這時候，你又想起設計模式，你從網上找來設計模式相關的博客，試圖引入相關設計模式到項目中。

通過屢次的學習，你是否已經學會了設計模式？我想答案是否認的。你能天然的說出設計原則嗎？你能說出大部分設計模式嗎？你能在項目不一樣業務場景中採用適當的設計模式嗎？你能在面試中對設計模式領域的問題對答如流嗎？

咱們爲何要學習設計模式？

有些人可能以爲，大牛不用刻意學習設計模式，很天然的就把它運用到編碼中了。對~這沒錯！但是，咱們大部分人都不是大牛，咱們須要刻意學習，以達到事半功倍的效果。

大牛們可能在一兩個項目實踐中就領悟到不少設計模式的思想精髓，而普通人可能在3、五年，甚至更長時間，才慢慢領悟設計模式（有可能始終都是模糊的狀態）。而咱們經過刻意學習，能夠更有效率的掌握設計模式。天然領悟就像「無師自通」，刻意學習就像跟着有經驗的師傅學習。畢竟「名師出高徒」的機率遠大於「無師自通」的機率。

寫出更好的代碼

編碼時，我經常會想，什麼是「好」的代碼。

從微觀角度，咱們能夠很容易的說出幾條：命名規範，詞能達意；運行效率高；節省內存；採用合理的數據結構和算法等。

宏觀層面（系統層面）來講，好的代碼是高聚合低耦合、擴展性強的。咱們怎麼才能寫出這樣的代碼呢？遵循基本的設計原則（如單一職責原則），採用合適的設計模式。設計模式就是前人總結下來的經驗，是各類業務場景下的經典解決方案。

提高開發效率

在實際項目中，迭代是很是頻繁的。新的功能不斷迭代，有時會發現新的功能跟系統已有功能很像，你想着這個好辦啊，直接複用原來的代碼就能夠了。但實際動起手來，才以爲事情不簡單啊：舊代碼並不支持直接複用，須要對原代碼稍做改動。改好以後，新功能能夠正常使用了。你覺得大功告成了，忽然測試同窗跑過來跟你說，原來的功能出問題啦！你才意識到新的改動影響了舊的邏輯！好吧~我舊代碼不動！copy一份代碼出來改造。

若是你使用了設計模式，系統具備很好的擴展性，每次迭代，不須要耗費大量精力考慮對舊業務的影響。這樣就能夠大大提高開發效率

面試須要

這多是最不值得一提的一點，面試並非學習的目的。但對咱們來講，它多是最重要的。

如何學好設計模式

回到最初的問題: 爲何學了不少次設計模式，仍是沒學會。有如下三個緣由：

1. 在學校的學習，沒有學以至用。
2. 應付面試的學習，沒有深刻學習。
3. 遇到問題的針對性學習，沒有系統學習。

深刻學習——追問事物的本質

若是隻是粗淺的學習設計模式，那隻會在腦海留下一個「印象」，隨着時間的推移，逐漸淡忘。追問事物的本質，就是大腦思考的過程。好比，學習某個設計模式，你思考這個模式的概念是什麼，爲何它重要，如何理解它，使用它有什麼意義，如何正確的使用它，它跟其餘同類的設計模式有什麼區別。

閱讀源碼，也是追問事物本質的一種方式。

系統學習——創建知識體系

咱們常說的融會貫通，就是各方面的知識或道理融合貫穿起來，從而獲得系統透徹的理解。創建知識體系，就是把各個知識點鏈接起來，造成一個知識網。系統全面的學習設計模式，就是創建設計模式的知識體系。當遇到實際問題時，你就能夠經過某個知識點及其千絲萬縷關係的找到問題的答案。

學以至用——應用所學知識

所學的設計模式，若是不實際應用到項目中，那一切都是紙上談兵。真正掌握設計模式就是能運用相應的設計模式解決實際問題。而實際應用設計模式，反過來又加深了對設計模式的理解。

The end

接下來我將持續更新設計模式系列文章，以「深刻學習」、「系統學習」、「學以至用」爲方向，與你們共同窗習設計模式！