現(xiàn)在還需要學(xué)習(xí)設(shè)計(jì)模式嗎?

最近面試了不少人，Java 和 dotNET 的都有，當(dāng)問到設(shè)計(jì)模式時(shí)，大部分都只能說出單例和工廠，有些能聊聊其他的一些模式的，大多也沒有在實(shí)際項(xiàng)目中用過。為了團(tuán)隊(duì)成員能有更好的編碼能力，便有了重新寫寫設(shè)計(jì)模式的想法，寫作也是一個(gè)重新學(xué)習(xí)的過程。

平時(shí)我們寫代碼，會(huì)有這樣一些情況：?

1、Leader 分配一個(gè)任務(wù)，比如要添加一個(gè)新功能，便找到相關(guān)的類，添加新的方法，然后就開始寫業(yè)務(wù)邏輯，各種循環(huán)、判斷，直到業(yè)務(wù)功能完成；?

2、修復(fù)一個(gè) Bug ，需要修改歷史代碼，某個(gè)方法被其他很多地方調(diào)用，怕改動(dòng)引發(fā)出新的問題，有時(shí)復(fù)制一個(gè)相同方法進(jìn)行修改；有時(shí)在方法參數(shù)中添加可空參數(shù)，然后根據(jù)參數(shù)值做判斷。

上面的做法都是最直觀、簡單的方法，不需要?jiǎng)幽X筋，一個(gè)程序員按照這種方法，工作一年便能輕松應(yīng)對日常工作，工作十年，可以稱之為擁有一年經(jīng)驗(yàn)的熟練工，永遠(yuǎn)成不了高手。

如果一個(gè)團(tuán)隊(duì)都像這樣做事，時(shí)間長了，會(huì)出現(xiàn)各種問題：

1、代碼看著有很多類似的，但每個(gè)地方又有些差別，不敢隨意修改；?

2、Bug 修復(fù)異常困難，容易漏掉場景；?

3、擴(kuò)展功能會(huì)牽一發(fā)而動(dòng)全身，需要加班加點(diǎn)，弄的疲憊不堪；

設(shè)計(jì)模式便是要打破我們的思維慣性，避免我們偷懶，強(qiáng)制我們思考的一個(gè)工具。

當(dāng)再遇到上面提到的任務(wù)或 ?Bug 修復(fù)時(shí)，可以換一種方式來思考：

1、分析新增功能的邊界和范圍，和現(xiàn)有功能的關(guān)系；

2、結(jié)合現(xiàn)有功能和新增的部分，看是否需要提取接口、類是否需要拆分、方法是否需要合并、參數(shù)是否需要擴(kuò)展；

3、整理出第一版設(shè)計(jì)后，就開始進(jìn)行編碼，過程中發(fā)現(xiàn)問題及時(shí)調(diào)整重構(gòu)；

4、在不斷優(yōu)化過程中，會(huì)慢慢發(fā)現(xiàn)，最后的代碼就符合某種模式了，所以說設(shè)計(jì)模式不是去生搬硬套，而是按照面向?qū)ο蟮脑O(shè)計(jì)原則逐步優(yōu)化出來的。

現(xiàn)在所說的設(shè)計(jì)模式是基于面向?qū)ο笳Z言，在面向?qū)ο笳Z言中有很多的設(shè)計(jì)原則，在學(xué)習(xí)設(shè)計(jì)模式前需要了解并掌握這些設(shè)計(jì)原則，原則的靈活運(yùn)用最終就體現(xiàn)成了各種模式，常用的原則有：

1、單一職責(zé)原則（SRP）：一個(gè)類應(yīng)該僅有一個(gè)引起它變化的原因；?

2、開放封閉原則（OCP）：類模塊應(yīng)該是可以擴(kuò)展的，但是不可以修改（多擴(kuò)展開放，對修改封閉）；?

3、Liskov 替換原則（LSP）：子類必須能夠替換他們的基類；

4、依賴倒置原則（DIP）：高層模塊不應(yīng)該依賴于底層模塊，二者都應(yīng)該依賴于抽象；抽象不應(yīng)該依賴于實(shí)現(xiàn)細(xì)節(jié)，實(shí)現(xiàn)細(xì)節(jié)應(yīng)該依賴于抽象；?

5、接口隔離原則（ISP）：不應(yīng)該強(qiáng)迫客戶程序依賴于他們不用的方法；

6、迪米特法則（LOD）：最小知識原則，類之間不該有直接關(guān)系的不要依賴，必須要有依賴關(guān)系的只依賴必要的抽象類或接口。

而到具體模式的學(xué)習(xí)就不得不提 GoF 23 種設(shè)計(jì)模式，這些設(shè)計(jì)模式在歷史性的一本經(jīng)典著作《設(shè)計(jì)模式：可復(fù)用面向?qū)ο筌浖幕A(chǔ)》中被描述的，這本書的四位作者并稱為 Gang of Four(GoF) 。

現(xiàn)在市面上各種設(shè)計(jì)模式的書籍以及其他資料都是源于這 23 種，發(fā)展到今天模式已經(jīng)遠(yuǎn)遠(yuǎn)不止 23 種，但我們只要學(xué)會(huì)了其根本就能夠應(yīng)對各種變化。

我們寫代碼時(shí)，引入任何的中間價(jià)、類庫、權(quán)衡之下，肯定是利大于弊，我們才會(huì)使用，設(shè)計(jì)模式也是一樣，如果只是盲目跟風(fēng)，套用模式，會(huì)變成過度設(shè)計(jì)，得不償失。初學(xué)者往往會(huì)犯這樣的錯(cuò)誤，覺得學(xué)習(xí)的模式得在項(xiàng)目中使用才行，找準(zhǔn)時(shí)機(jī)就去套用。在學(xué)習(xí)過程中這樣進(jìn)行練習(xí)是可以的，但真實(shí)項(xiàng)目中，一定得去思考現(xiàn)在的方式有什么樣的問題，為什么需要進(jìn)行重構(gòu)，然后才是思路和方法，得到最終的模式。

設(shè)計(jì)模式常常會(huì)按照創(chuàng)建型、結(jié)構(gòu)型和行為型進(jìn)行分類，其實(shí)很多模式并不常用、很多模式有很多的相似性。根據(jù)我自己的經(jīng)驗(yàn)，我認(rèn)為一個(gè)好的學(xué)習(xí)路徑是：

1、先學(xué)習(xí)面向?qū)ο螅缓笳莆彰嫦驅(qū)ο蟮脑O(shè)計(jì)原則；

2、學(xué)習(xí)常用的模式，多個(gè)模式可以對比起來學(xué)習(xí)；

3、搞懂模式能解決什么問題，和相似的模式應(yīng)該怎么區(qū)分和選擇；

4、結(jié)合實(shí)際的開發(fā)場景學(xué)習(xí)怎么應(yīng)用；

5、閱讀下 dotNET Core 源碼，看看能不能發(fā)現(xiàn)使用了哪些設(shè)計(jì)模式。

后續(xù)的文章也大致會(huì)按照這個(gè)思路進(jìn)行，不會(huì)按照常規(guī)的順序、也不一定會(huì)每一個(gè)都介紹到，盡量做到最有價(jià)值的輸出。

最后想說的是，程序員都應(yīng)該學(xué)習(xí)設(shè)計(jì)模式，尤其是能養(yǎng)成一個(gè)使用設(shè)計(jì)思維的方式去處理問題更是一個(gè)程序員的必修課。