引子：想象一下一個廚師，不學菜名如何跟人快速的交流。回鍋肉，魚香肉絲，龍井蝦仁，獅子頭，叫花雞。請你換一種方式來介紹試試看。
設計模式也是，作為程序員之間的共同語言有必要學習下，別人講個模式，而你並不懂，尷尬不，溝通成本也變高，當然更為重要的原因是，這是前輩們這么多年摸滾打爬總結總結出來有效經驗總結，重要性自然不必多說，在我看來，學習設計模式的必要性就跟1+1=2一樣明顯。
筆者就遇到這樣的情況，從事java開發工作也快兩年了，有時跟同行交流下，直接聊死，因為對於這一塊用到不多，知道有23種模式，但只用過幾種，其他是一個模糊的概念，故覺得有必要系統的學習了解下，因為網上的文章良莠不齊，所以筆者選擇了：【書+實際應用的經歷】這種方式來進行學習（后面會介紹到筆者用到的書）。
這篇文章作為【設計模式就該這么學】系列的第一篇：是用來學習設計模式的預熱，主要是談一下為什么要學習設計模式！
后續，我會將每個設計模式單獨成文，這些文章的的代碼和文字將會基於實際的應用例子和書《Head First設計模式》根據自己的理解整理成文寫出來，若有偏差，歡迎指正！
《設計模式就該這么學》系列文章:
一、什么是設計模式？
比起百度百科的解釋，我更喜歡《研磨設計模式》一書中的定義，如下：
在軟件開發領域，經過驗證的，用於解決在特定環境下，重復出現的特定問題的解決方案！
注意上面提到的限定詞，現在按我的理解來解釋下。
1、軟件開發
其實我覺得各行各業都有模式可以套用，這里的設計模式指的是在軟件開發領域。
2、經過驗證的
必須是經過大家公開驗證的解決方案才算得上是設計模式，而不是說每個人隨便工作解決的問題方案都算
3、特定環境
個人理解為就是不要脫離特定環境去使用設計模式，拿命令模式來說吧，我們開發中，請求-響應模式的功能非常常見，一般來說，我們會把對請求的響應操作封裝到一個方法中，這個封裝的方法 可以稱之為命令，但不是命令模式。到底要不要把這種設計上升到模式的高度就要另行考慮了，因為，如果使用命令模式，就要引入調用者、接收者兩個角色，原本放在一處的邏輯分散到了三個類中，設計時，必須考慮這樣的代價是否值得，所以有必要考慮下環境。
4、重復出現
因為只有重復出現的問題才有必要形成固定方案，下次使用直接套用就是。
5、特定問題
不要覺得只會一種模式就可以走遍天下，那還要其他的模式做什么卵用，畢竟每種模式是針對特定問題的解決方案。
每個設計模式的構成如下：
1、模式名稱：模式的一個好記的名字
2、環境和問題：描述在什么環境下，出現什么特定的問題
3、解決方案：描述如何解決問題
4、效果：描述應用模式后的效果，以及可能帶來的問題
二、為什么需要學習設計模式
1、避免重復造輪子
前言也提到這是前輩們這么多年摸滾打爬總結總結出來有效經驗總結，在特定環境下使用肯定事半功倍。比如我之前用觀察者模式就很好地解決了實時解析某個指定目錄下文件入庫操作，后面會介紹
2、溝通更高效
農民b：那我大致了解你是怎么做的了
中農c：c，我覺得你這段代碼可以應用XXX設計模式的
農民d：以我的理解在這種這個模塊下，不適合用這種模式
3、易維護
因為遵循一個約定（即設計模式）寫了一套代碼，那么知道這一套約定的人就很容易理解的你的代碼，維護自然更容易。
4、心法或意識形成
為什么一個相似的功能，大牛一會兒就搞定，然后悠閑地品着下午茶逛淘寶；而自己加班加點搞到晚十點還做不完。
為什么大牛寫完的程序測試上線后，幾乎完美運行，用戶無懈可擊；而自己的程序bug重重，改好一個卻又引出另一個，按下葫蘆浮起瓢，幾近崩潰。
這不僅僅是因為大牛們工作比你久，是因為人家腦袋里就有這樣的意識，在遇到特定的問題，人家很自然就能冒出這樣的想法，同樣的功能人家就是寫出的代碼就死可以比你的更容易維護，
系統也就更穩定。而你為什么不能，因為你根本就不知道有設計模式可用。
學習本就是一個不斷模仿、練習、再到最后面自己原創的過程。
雖然可能從來不能寫出超越網上通類型同主題博文，但為什么還是要寫？
於自己而言，博文主要是自己總結。假設自己有觀眾，畢竟講是最好的學（見下圖）。於讀者而言，筆者能在這個過程get到知識點，那就是雙贏了。
當然由於筆者能力有限，或許文中存在描述不正確，歡迎指正、補充！
感謝您的閱讀。如果本文對您有用，那么請點贊鼓勵。
