# 文章首發於公眾號「陳樹義」及個人站點（[https://shuyi.tech](https://shuyi.tech/)），歡迎訪問。 ## 設計模式的本質 說起設計模式，就不得不說起重構。在 2017 年，當我還是一個工作 3 年的菜鳥，我重構了公司一個十幾年的老系統，弄得心力交瘁。為了能深刻吸取這次重構的教訓，我寫了一篇文章記錄這次重構的心得：[淺談重構中踩過的坑 - 陳樹義的部落格](https://shuyi.tech/archives/some-experienc-in-system-refactor)。 時隔三年，我再次刷了一遍設計模式相關知識，這次我對設計模式有了更深刻的認識。所以今天我們就來聊聊：設計模式的本質是什麼？它的存在有什麼價值？學了設計模式有什麼好處？ 在這篇文章中，我對設計模式的總結是：**設計模式用於承載複雜的業務邏輯，使寫出的程式碼簡潔、易擴充套件。** 簡單地說，你需要去了解業務中哪些是變化的，哪些是不變的。這些變化的東西就是複雜的業務邏輯，你需要思考如何用一種合適的設計模式去承載它，使得當它發生變化的時候，能具有很好的擴充套件性。這時候如果你學過設計模式，對每種設計模式的使用場景都諳熟於心，那你做起來會更加得心應手。 有些人說，我看有些人也沒學過設計模式，但他們程式碼也寫得挺好啊。**這裡我想表達我的第二個觀點：抽象思維才是設計模式的核心。** 有些人接觸的專案多了，其在專案中不知不覺地就用到了一些設計模式。這些人一般都具有一個共同點：抽象總結能力強。他們接觸到了東西多了，會不斷思考他們的共同之處，然後試圖總結出經驗。如果你具有這種抽象的思維，那即使你沒看過設計模式，你也能寫出類似於設計模式的程式碼。甚至到最後，你也可以設計出一種獨特的設計模式。到時候你可能就成為了自創門派的「一代宗師」了。 ## 設計模式的價值 對於設計模式，不少人也有很多見解。有的人覺得設計模式名過其實，實際程式設計中遠遠沒有那麼重要。在我看來，設計模式存在即合理，至少它有下面三點實在的意義。 **設計模式是經驗沉澱，便於後來者快速學習。** 人類之所以能一代更比一代強，靠的就是用文字元號實現經驗傳承。而在程式設計領域，我們的設計模式其實就是前人在實戰中的經驗總結，他們將這些經驗歸納出來成為設計模式。 對於經驗不是很多的人來說，學習設計模式可以讓他們有個初步的印象，等到他們有對應的專案經驗時，他們可以更好地應用上。而對於專案經驗豐富的人來說，設計模式可以豐富他們的專案場景，進一步提高他們對於複雜場景的掌控。 **設計模式可以方便交流。** 有些同學會覺得一些設計模式自己都用過，只不過先輩們給它起了個名字而已，沒什麼大不了的。但不知道這位同學是否有思考過：為什麼要給各個設計模式起一個名字？ 我們的知道有顯性知識和隱形知識之分。顯性知識就是大家一說，我們都能聽得懂的。例如錘子可以用來釘釘子，例如搜尋引擎可以用來搜尋知識。而隱形知識則是指那些我們做事的經驗，我們很難描述出來的東西。 我們這裡說的設計模式，落地下去其實就是對應的程式碼結構。但我們如何將這種實戰中的經驗描述出來呢？一個最直接的方法是：我每次跟別人交流的時候，我都說：你這個建立一個介面，然後這個類繼承這個介面，然後 bla bla …… 可能你說了半天，人家也還沒聽懂。即使聽懂了，你下次還是得嘰裡呱啦說半天，別人才能聽得懂。 怎樣才能讓別人一下子領會到我們的意思呢？很簡單，就是給這種程式碼結構起個名字嘛！這也才有了工廠方法、策略模式、模板模式這些名詞。當你跟別人一說這個名字，別人就知道是怎麼回事，這不就大大提高了溝通效率嘛！ 生活中其實也有很多類似的例子。我們為什麼會有很多思考模型，例如：SMART 模型、PDCA 模型？本質上就是用來幫助記憶，以及便於溝通的。 想想看「搜尋引擎」這個詞，在 50 年前還不存在，那為什麼有搜尋引擎這個詞呢？不就是為了便於交流，讓別人知道是怎麼回事嗎？假設沒有「搜尋引擎」這個詞，我們要描述百度，我們得怎麼描述？我們試一下：就是你開啟一個網頁，輸入詞語，然後會挑出來一大堆相關的資訊。這樣還是挺麻煩的吧。 想想「五花肉」這個詞，可能在古代還真沒這個詞。那我們要怎麼形容？古代人說：就是那種一點肥、一點瘦的豬肉。現代人三個字搞定：五花肉！多高效啊！ # 文章首發於公眾號「陳樹義」及個人站點（[https://shuyi.tech](https://shuyi.tech/)），歡迎訪問。 ## 學設計模式的好處 聊完了設計模式的本質和意義，最後我們聊聊設計模式的好處。 **提高系統設計能力，程式碼更簡潔，更易於擴充套件。** 在網際網路公司幹過的都知道，研發流程裡最確定的東西就是變化本身。需求是不可能一成不變的，唯一不變的就是需求會一直變。這就對研發人員提出了更高的要求，需要在系統設計的時候考慮到後續的擴充套件。 **設計模式本質上就是對變化的封裝，用結構化的程式碼結構去承載變化的需求。** 當你明白這一點後，你需要做的就是去分析出系統中變化的部分，之後採用合適的設計模式（程式碼結構）去實現。只要變化的部分拆解得好，那你就有足夠強大的結構去應付變化的需求。 在這一個層次上，考驗的其實是你對業務的理解，還有你掌握的設計模式的數量。這些將直接決定你是否能抽離出變化的部分，而抽離出變化的部分之後，你能不能找到合理的設計模式去承載。如果找不到，那你的「抽象思維」層次決定了你是否能自我創造一種設計模式。 **設計模式可以幫助閱讀原始碼、寫框架。** 在我們現在使用的不少框架中，都使用了很多的設計模式。越是底層的系統，他們就需要越抽象，他們使用到的設計模式就越多。例如：Spring 框架中使用到的設計模式就多達十幾種，有工廠模式、代理模式、模板模式等等。 當你理解了這些設計模式之後，你再去閱讀原始碼，你就能夠更快速地領會框架作者的意思。否則你看原始碼只會像看天書一樣，完全看不懂，還吐槽這程式碼怎麼這麼垃圾。 **設計模式有利於你面試。** 這點可以說是挺功利的一點，但也確實是最實在的一點。工作三年以上的工程師，至少要會學習一些設計模式。只有掌握了合理的設計模式，你寫的功能才能更易於擴充套件。這也是我們這些工作多年的老碼農，和剛畢業的小年輕的區別。 如果你工作了好幾年，寫程式碼的時候還是從頭寫到尾短平快，不考慮一點擴充套件性，那麼你可能真的很容易被替代。現今的面試中，也越來越考察面試者的程式碼編寫能力了。掌握設計模式的思維方式，可以幫助你在面試中拿到更多的籌碼、贏得更高的薪資。 ## 小結 設計模式本質上是用於承載變化的業務邏輯，使寫出的程式碼簡潔、易擴充套件。它們就像武功中的招式，但具體的招式並不是目的，抽象思維才是設計模式的核心。掌握了抽象的思維，你也能設計出屬於自己的模式。 設計模式是前人經驗的總結，便於後來者快速學習。設計模式與菜名、標籤一樣，是對程式碼結構的一種描述，便於我們交流。掌握了設計模式，能夠讓我們提高系統設計能力，使系統更易於擴充套件。同時也能讓我們讀原始碼、寫框架時事半功倍。  # 文章首發於公眾號「陳樹義」及個人站點（[https://shuyi.tech](https://shuyi.tech/)），歡迎訪問。 ## 參考資料 * [為什麼要學習設計模式 | 大專欄](https://www.dazhuanlan.com/2020/02/24/5e5364a7d090a/) * [設計模式就該這麼學：為什麼要學設計模式？（開篇漫談） - 騎白馬的菜鳥 - 部落格園](https://www.cnblogs.com/zishengY/p/88471