摘要：不少人對設計模式都有些疑問或者說是質疑：寫程式碼一定要用設計模式嗎？用了設計模式的程式碼就比沒用的好嗎？
本文分享自華為雲社群《走近設計模式：寫程式碼一定要用設計模式嗎？》，原文作者：技術火炬手 。
不少人對設計模式都有些疑問或者說是質疑：
- 寫程式碼一定要用設計模式嗎？
- 用了設計模式的程式碼就比沒用的好嗎？
為了解答第一個問題，我們需要去調研一下什麼是設計模式，這包括瞭解設計模式產生的初衷、設計模式能否幫我們解決軟體問題等；而為了解答第二個問題，就需要去掌握如何使用設計模式，何時何地使用何種設計模式，什麼時候應該使用、什麼時候需要遠離。
什麼是設計模式？
前段時間面試候選人的時候問過這個問題——“什麼是設計模式？”。候選人答到，“設計模式有單例模式、觀察者模式、代理模式......“。我沒有打斷他，還是順著問了他對這幾個模式的理解。雖然這並不是我想問的，但我猜測會這樣回答的人應該不在少數。
“設計模式”或者是“Design Patterns”，無非是一種設計的模式，設計這裡是指軟體設計，再具體一點是“物件導向的軟體設計”，而模式這個概念比較籠統，各行各業都有模式，用白話說就是一種“套路”，是一種可以複製的經驗。
提起設計模式，有一本繞不開的經典《設計模式：可複用物件導向軟體的基礎》，除了設計模式，還有一個副標題——可複用物件導向軟體的基礎，限定了複用和麵向物件。書中首先是丟擲了幾個觀點：
- 設計物件導向軟體比較困難，而設計可複用的物件導向軟體就更加困難。
- 有經驗的物件導向設計者能做出良好的設計，而新手卻無從下手。
- 不是解決任何問題都要從頭開始，內行的設計者更願意複用以前使用過的解決方案。
然後給出了一個不是很好理解的設計模式的定義：對用來在特定場景下解決一般設計問題的類和相互通訊物件的描述。講人話就是特定問題的可複用的解決方案。這裡可複用的概念比較含糊，我更願意理解為實際專案中總結出來的，解決特定問題的最佳實踐。
這種最佳實踐可以來自於他人總結，典型的來源是各種書籍和原始碼；還有一個更重要的來源便是自身軟體開發經驗的總結。
什麼時候使用什麼模式？
解決特定問題的最佳實踐。顯然解決問題A的最佳實踐往往並不能解決問題B，至少不會是解決問題B的最佳實踐，那麼我想這裡至少要面臨兩個問題：
- 某種設計模式解決的是什麼問題？
- 我的問題等於某種設計模式解決的問題嗎？
得到了上面兩個問題的答案後，接下來的才是設計模式如何解決我的問題。
這兩個問題是以我的思路提出來的，同時我也覺得這是兩個很糟糕的問題，下面我會做說明。
首先，我並不建議新手直接學習如何使用各種設計模式，比如那23種。學習的結果往往是掌握瞭如何用程式語言實現某種設計模式，卻對該設計模式解決了什麼問題沒有深刻的印象。這種先入為主會讓學者覺得設計模式很簡單，然後在實際的開發中為了使用模式而使用，並沒有解決實際的問題。因為我是這麼幹的，所以覺得有更好的方式。
一個建議是，在新手階段，按這個步驟去學習設計模式：
- 多花點時間去了解軟體設計上有哪些常見的設計問題、疑難雜症
- 哪些問題已經有了最佳實踐的解決方案，或者說設計模式，哪些還沒有
- 深入體會設計模式解決該問題的過程，最好能親身參與該過程
這個思路是先有問題後有模式，大腦中形成的思路是透過問題檢索模式，而不是孤立的模式，或者是模式檢索問題的迴路。
到這裡我們在看一下上面兩個問題，是一種拿著答案找問題的思路。實際的場景應該拿著問題找答案。我們重新調整一下：
- 我要解決的問題是什麼？
- 我的問題是否等於已經存在的問題A
- 是否有解決問題A的設計模式
透過學習有哪些常見的設計問題以及對應的模式，我們也只能回答問題3。
而問題1和問題2跟設計模式沒有任何關係，卻是能不能應用某種設計模式的第一步。這也是導致設計模式濫用的根源，同時也是很多人放棄設計模式的原因。
關於如何去回答這兩個問題，小弟暫時沒法給大家解答。分析問題的能力，可能需要時間的積累吧。
設計模式的牢籠
設計模式按解決特定問題的最佳實踐來定義本身沒有錯，但往往有人陷進了設計模式的牢籠。
以GoF設計模式為例，雖然那23中設計模式是由比你我更加聰明的程式設計師總結出來的，但使用它們也不是沒有代價的。
- 設計模式不是現成的程式碼，它不像類庫可以直接使用
- 設計模式大都是解決程式碼擴充套件性的問題，但這裡的擴充套件性真的是你需要的嗎，是不是過度設計
- 設計模式提升擴充套件性的方式往往是增加抽象，這就犧牲了簡單性
這裡再看一下開篇的兩個問題：
問：寫程式碼一定要用設計模式嗎？
答：不是，不是所有問題都有現成的解決方案。
問：用了設計模式的程式碼就比沒用的好嗎？
答：不是，也許更差。
學習設計模式的好處
雖然設計模式不是銀彈，掌握設計模式也不一定能幫你解決你正面臨的問題，但學習一下設計模式對你的軟體開發工作還是大有裨益的，就算你永遠不使用它。
如果不忽悠下讀者學這個還是有點用的，那寫後續的系列文章意義在哪......
1.應對面試中的設計模式相關問題
就很直接，如果你是被面試的，被問到的機率不低；如果你面試別人，可以用來考察下候選人的理解程度。
2.讓讀原始碼、學框架事半功倍
優秀的開源專案中類的個數都會比較多，類結構、類之間的關係極其複雜，常常呼叫來呼叫去。為了保證程式碼的擴充套件性，程式碼中會使用到很多設計模式，當然也不排除作者秀的嫌疑，但是如果你不懂設計模式，看開原始碼經常摸不著作者的設計思路，看起來找不到北。
3.為你的職場發展做鋪墊
公司裡面code review，你連幾個設計模式都說不出來，一看就不是“大牛”，嗯，就是這樣的。
4.提升你的程式碼設計能力
這一點要看造化，但這是客觀存在的，你總會遇到需要設計複雜系統的時候，早接觸早準備。