[[394247]]

前言

不知道隨著大家工作年限的增長，有沒有一種危機感，害怕自己的技術(shù)深度開始沒有提升，所以經(jīng)常會去看一點框架的源碼，或者報一些網(wǎng)課去提升自己。

最近我有一個老東家的同事跟我聊起來這個問題，說最近剛換公司了，但是自己的寫的代碼感覺很“low”，在codereview的時候總能被提出各種建議，幾年經(jīng)驗了還在犯那種新手的錯，寫代碼毫無模式和設(shè)計美感可言。

而且在想學(xué)習(xí)技術(shù)深度的時候(看一寫框架的源碼)總感覺只理解了表面，而沒有理解里面的思想。

這里大家應(yīng)該都知道我想說什么了，沒錯就是 設(shè)計模式，其實這也是我剛工作第一年第二年不斷在思考問題，為什么要學(xué)設(shè)計模式?設(shè)計模式優(yōu)點有哪些?

提升查看框架源碼的能力

提升自己對復(fù)雜業(yè)務(wù)的邏輯的代碼設(shè)計能力以及code能力

對面試以及后面的職場道路打下扎實的基礎(chǔ)

比如我之前做電商活動的時候，我之前做會場活動的小伙伴就用了責(zé)任鏈+工廠+單例的模式，我只需要多個工廠類型，然后責(zé)任鏈傳遞，復(fù)用他的單例就ok了，這就是設(shè)計模式的好處，可以裝X還可以造福后人。

正文

今天我就聊一下工廠模式，工廠模式在我們的電商領(lǐng)域的應(yīng)用是非常廣泛的。寫之前我看了自己電腦項目的代碼，確實隨處可見。

工廠模式主要可以分為三大類：

• 簡單工廠模式
• 工廠方法模式
• 抽象工程模式

今天我也主要圍繞這三種模式來舉例了解一下

簡單工廠模式

工廠模式主要是用于對實現(xiàn)邏輯的封裝，并且通過對公共的接口提供對象的實列畫的服務(wù)，在我添加新的類時不需大動干戈，只要修改一點點就好。

舉個例子我之前所在的電商業(yè)務(wù)怎么創(chuàng)建創(chuàng)建商品的：

在這個簡單工廠里面，如果要創(chuàng)建活動商品1 以及活動商品2，我們要創(chuàng)建商品的時候只要調(diào)用簡單工廠里面的創(chuàng)建商品方法，根據(jù)類型創(chuàng)建出不同的商品然后實列化返回就可以了。

簡單工廠幾種實現(xiàn)方式：

靜態(tài)工廠模式

我們還是以創(chuàng)建商品為列子

這種方式創(chuàng)建看起來其實也沒什么問題，根據(jù)類型創(chuàng)建不同的商品，但是有一個問題不知道大家發(fā)現(xiàn)沒有?

是不是我每增加一種類型是不是我還要去修改createProduct方法的 if else?這不是違背我們的開閉原則嗎?

所以這種方式不好，我們還有接來的兩種：

• 使用反射機制
• 直接注冊商品對象，添加一個Type類型方法，根據(jù)type類型返回自身相同類型的方法

同樣的我們還是以創(chuàng)建商品為列：反射實現(xiàn)

看上面的代碼，我發(fā)現(xiàn)反射其實也很容易就實現(xiàn)了，但是在一些特定的情況下，并不適用，而且在某些特定的情況下是無法實現(xiàn)的，而且反射機制也會降低程序的運行效果，在對性能要求很高的場景下應(yīng)該避免這種實現(xiàn)。

• 這里還有一個問題適用反射不當(dāng)是容易導(dǎo)致線上機器出問題的，因為我們反射創(chuàng)建的對象屬性是被SoftReference軟引用的，所以當(dāng)**-XX:SoftRefLRUPolicyMSPerMB** 沒有設(shè)置好的話會一直讓機器CPU很高。
• 當(dāng)然他的默認(rèn)值是1000，也就根據(jù)大家的情況而定吧，反正就是注意一下這點。

剩下的一種其實很反射實現(xiàn)很像，就是為了避免使用反射，在Map的對象中不是存的要添加的類，而是將要添加的每種類對象實列。這個我就不寫demo了😂

工廠方法模式

工廠方法模式是對靜態(tài)工廠模式的上的一種改進，我們的工廠類直接被抽象化，需要具體特定化的邏輯代碼轉(zhuǎn)移到實現(xiàn)抽象方法的子類中，這樣我們就不要再去修改工廠類(即：不用再去做什么if else 修改)這也是我們當(dāng)前比較常用的一種方式。

還是我們以創(chuàng)建商品為例：

看這張圖 其實就是說白了再創(chuàng)建一個工廠，用來創(chuàng)建工廠類對象

接下來我們看下代碼怎么來實現(xiàn)這個功能吧：

這里我們先創(chuàng)建一個抽象工廠方法

再創(chuàng)建一個商品工廠去繼承抽象工廠方法。

當(dāng)還有其他類型的時候我們只要去繼承我們創(chuàng)建的工廠方法可以了

• 這個代碼大家肯定都能實現(xiàn)出來，但是我們真正的需要學(xué)習(xí)的是前輩們的這種工廠模式的思想。把這種思想運用到我們真實的業(yè)務(wù)場景中，學(xué)以致用才能對我們有真正的提升。

我再給大家舉一個列子：學(xué)以致用

假設(shè)現(xiàn)在leader要你做一個分享商品圖片，我們知道商品的類型 有很多，比如 無SKU 商品，有SKU 商品，下單分享，邀請分享......等一系列的場景。那我們怎么去設(shè)計這個代碼做到更加的易懂，易讀，今后擴展性好呢?

• ps：sku和spu是我們電商里面的名詞，spu差不多跟item也就是商品是一個維度，一個商品item有很多sku，比如：iphone是一個商品是item 也是spu，白色的iphone 12 64G 就是一個具體的sku。

第一步我們應(yīng)該都是定義一個創(chuàng)建分享模版

第二步我們再創(chuàng)建一個分享工廠根據(jù)我們的類型獲取我們預(yù)先加載在Spring容器中的bean實列

最后就是定義我們不同的類型來實現(xiàn)分享圖片。

• 其實我們學(xué)習(xí)設(shè)計模式就是這種思想，有了這種思想 上面提到的三點優(yōu)勢才能體現(xiàn)出來對我們今后的成長，面對復(fù)雜業(yè)務(wù)設(shè)計以及思考能力才能提升。

那么問題來了，什么時候該用工廠方法模式，而非簡單工廠模式呢?

• 這里引用設(shè)計模式之美里面的一句話：當(dāng)對象的創(chuàng)建邏輯比較復(fù)雜，不只是簡單的 new 一下就可以，而是要組合其他類對象，做各種初始化操作的時候，我們推薦使用工廠方法模式，將復(fù)雜的創(chuàng)建邏輯拆分到多個工廠類中，讓每個工廠類都不至于過于復(fù)雜。
• 而使用簡單工廠模式，將所有的創(chuàng)建邏輯都放到一個工廠類中，會導(dǎo)致這個工廠類變得很復(fù)雜

抽象工廠模式

看完工廠方法模式，再理解抽象工廠模式就更加簡單，因為它其實就是工廠方法的一個延伸。

• 工廠方法類中只有一個抽象方法，要想實現(xiàn)多種不同的類對象，只能去創(chuàng)建不同的具體工廠方法的子類來實列化，而抽象工廠 則是讓一個工廠負(fù)責(zé)創(chuàng)建多個不同類型的對象

感覺理解起來有點繞，我們還是來畫個圖吧

樣子可能有點丑，但是能說明問題，其實看上去可以分為以上幾個部分組成：

• 抽象工廠類
• 具體工廠類
• 抽象類

抽象工廠類我個人可以理解為一個剛出廠的手機，具體抽象工廠這是認(rèn)為我們每個人對這個手機壁紙自定義設(shè)置，最后抽象類我理解就是手機壁紙。

我們每個人可以自定義不同壁紙比如：動圖妹妹，靜圖風(fēng)景，小傻瓜等等。

結(jié)尾

我在幾家電商公司任職期間，見過很多大佬的代碼，怎么形容呢，就是各種各種設(shè)計模式，看起來真的無敵優(yōu)雅，然后我們接入的時候還很方便，直接傳參數(shù)就好了。

我們的業(yè)務(wù)代碼中設(shè)計模式本身就是無處不在的，我在寫這個文章的時候刻意翻看我們以前的項目，基本每個項目里面都能看到他們的身影，在跟我前同事聊過之后體會更深了。

其實我們想要走的更高更遠(yuǎn)，那我們學(xué)習(xí)的腳步就不能一直停下，后面我可能會針對設(shè)計模式寫一個互聯(lián)網(wǎng)公司的流程引擎，來看看我們針對更復(fù)雜的業(yè)務(wù)邏輯我們怎么運用框架去實現(xiàn)它。

我是敖丙，你知道的越多，你不知道的越多，感謝各位人才的：點贊、收藏和評論，我們下期見!