大學+工作十年，師長學不動了，別問我多少年經驗，問就是20年，加班加出來的。
點贊收藏，養成好習慣！

哈嘍，大家好，我是高冷就是範兒，又和大家見面了。?從今天開始我將正式開啟有關設計模式的系列文章的寫作，和大家一同來聊聊設計模式這個老生常談的玩意。關於設計模式的文章，書籍，多如牛毛，隨便百度、Google一下都能給你搜出不計其數關於講解設計模式的文章來。

❓那為什麼我還要花費如此大的精力和時間，來寫這麼個耳熟能詳的東西呢？

寫作原因

首先，肯定不是因為我對設計模式有多精通。其實我也只是一個正在學習路上的菜鳥，接下去寫作過程中必然也需要查閱一些其它大佬們的資料來完善文章。我之前完整學習過設計模式，也做了一些筆記，所以希望能將學習過的知識做輸出，分享給大家。

關於設計模式的文章確實有很多，但是我發現內容雷同比較多，甚至連內容的結構也比較統一單調，連文章的風格也都相去不遠。設計模式屬於技術體系中比較理論的內容，比較枯燥，要是再套用書本上那種正式嚴肅的風格去寫，會比較痛苦。

另外，有些文章篇幅相當長，裡面各種圖啊，程式碼啊貼的也不少，寫的很是詳細，當然初衷肯定是好的，希望能夠幫助大家更好去理解。但是看著比較痛苦。好幾次當我很痛苦的讀完之後，發現還是沒有把東西講清楚，也不知道有什麼用，還得去查閱其他資料。當我最後弄明白是咋回事後再回頭看，發現這個玩意也並不是很複雜啊？為什麼會講的如此之複雜......

學習設計模式從忘記設計模式開始。

基於這些問題，所以我決定還是應該炒炒冷飯（冷飯這名字還挺適合我~）寫點設計模式的文章，我希望這次寫作可以儘量拋棄書本上的教條框架，忘記自己曾經學習過設計模式，重新歸零，從心出發，用自己比較通俗直白的方式，但又不失深度的將知識呈現給大家。

結合生活場景和框架原始碼。

同時，在後續的文章中，我也會盡量用生活中熟悉場景作為例子解釋。當你真的學完每一個設計模式，並有過一些思考，會發現設計模式不再枯燥乏味，生活處處都會有它的身影。

另外，在技術領域，設計模式大量存在於各類主流開源框架中，其中以Spring，Mybatis等為典型代表，設計模式在其中被運用的爐火純青。後續我也會挑選一些自己瞭解過的原始碼結合著聊。當你看懂其中的運用，你會不由讚歎設計者構思之精巧。

總體來講，我希望我的文章不會是循規蹈矩，嚴肅死板的，以一種比較輕鬆、隨意的風格進行的。文章的篇幅儘量簡短精煉，能用一句話講清楚絕不贅述。而且設計模式中，其實常用的模式就那麼幾種，所以我寫的過程會有主次之分，重要我會詳解，簡單的或者幾乎不用的模式我就一帶而過了。當然如果大家有啥好的建議也可以告訴我。

今天是開篇導言，不涉及具體的模式的內容講解，但是開宗明義，我還是想簡單講一下設計模式相關的概念。

是什麼

❓設計模式到底是什麼？

在這裡我就不把設計模式的概念複製一遍了，我寫著累，你們看著也累，而且前面說了，這個系列文章我儘量想用比較輕鬆、隨意的風格寫。總結起來就一句話，設計模式就是一些過去技術的大師們總結出來的一系列寫程式碼的套路。

大佬們經過實踐總結又將其這些套路分為三類，建立型、結構型、行為型。

顧名思義，建立型模式，是為了建立物件使用的，至於為什麼建立個物件（直接new一個不就完事了嗎）還需要如此多不同的套路，後續你就知道，這邊不贅述。結構性模式，是用來組織不同的小物件，從而變成更大更復雜結構的物件。行為型模式，是用來控制協調不同的物件的執行流程，因為實際開發場景下，不可能是孤零零一個物件在執行，會涉及多個物件互動，這中間的協調工作就會使用到行為型模式。

每一型別的模式都包含多個具體模式，如下圖。後續每篇文章都會對其中一個模式做詳解剖析，這邊就不再贅述。

為什麼

❓這些套路到底好在哪裡？

很多人學設計模式覺得很難，很重要原因是，不知道這個模式到底好在哪裡？解決了什麼痛點？我能用它來幹啥?所以只能生搬硬套。其實模仿也是無可厚非的，進步就是從模仿優秀者開始的。但是如果想要能駕馭一門知識，還是需要了解其本質的。

所以這邊需要提一下一個跟設計模式緊密相關的概念——面向物件的七大設計原則。其實，如何評判一個設計模式好壞，就是用這七個原則來衡量的。這些原則有開閉原則、里氏替換原則、依賴倒置原則、單一職責原則、介面隔離原則、迪米特法則、組合聚合複用原則。還是比較抽象的，但是我這邊就不展開了，大家也沒必要去死記硬背這些原則，沒意義。後續在講到每個設計模式的優缺點時候，我會穿插提到這些設計原則，到時再做詳解。

❓設計模式一定需要用嗎？

這邊先潑個冷水，這個設計模式系列你看完，你還真不一定能立刻用上，甚至有的時候你用了還是畫蛇添足，會給應用帶來一些不必要的問題和麻煩。尷尬......設計模式對不同層級的程式（應用層級、類庫層級、框架層級）重要性不一樣。設計模式更多可能會用在一些類庫和框架的設計，或者對老專案重構，在業務邏輯開發中使用的比較少，甚至會引入不必要的複雜度。

當用則用，不合適，或者感覺沒把握，千萬不要強上！?當你的開發受到阻礙，亟需一條出路，哎，這個時候設計模式可以登場了......

❓那這是為什麼呢？

因為像類庫框架這類產品，會被不同的人大量重複使用，所以對其重用性、擴充套件性、靈活性有很高的要求。而對於普通的業務邏輯開發，這方面要求較低。

怎麼辦

還能怎麼辦？學唄......?下一篇我就會開始寫第一個設計模式——單例模式，讓咱們一起探討設計模式的奧祕吧。不見不散。??