[[394247]]

前言

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

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

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

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

提升查看框架源碼的能力

提升自己對復雜業務的邏輯的代碼設計能力以及code能力

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

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

正文

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

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

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

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

簡單工廠模式

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

舉個例子我之前所在的電商業務怎么創建創建商品的：

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

簡單工廠幾種實現方式：

靜態工廠模式

我們還是以創建商品為列子

這種方式創建看起來其實也沒什么問題，根據類型創建不同的商品，但是有一個問題不知道大家發現沒有?

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

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

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

同樣的我們還是以創建商品為列：反射實現

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

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

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

工廠方法模式

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

還是我們以創建商品為例：

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

接下來我們看下代碼怎么來實現這個功能吧：

這里我們先創建一個抽象工廠方法

再創建一個商品工廠去繼承抽象工廠方法。

當還有其他類型的時候我們只要去繼承我們創建的工廠方法可以了

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

我再給大家舉一個列子：學以致用

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

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

第一步我們應該都是定義一個創建分享模版

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

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

• 其實我們學習設計模式就是這種思想，有了這種思想 上面提到的三點優勢才能體現出來對我們今后的成長，面對復雜業務設計以及思考能力才能提升。

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

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

抽象工廠模式

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

• 工廠方法類中只有一個抽象方法，要想實現多種不同的類對象，只能去創建不同的具體工廠方法的子類來實列化，而抽象工廠 則是讓一個工廠負責創建多個不同類型的對象

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

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

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

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

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

結尾

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

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

其實我們想要走的更高更遠，那我們學習的腳步就不能一直停下，后面我可能會針對設計模式寫一個互聯網公司的流程引擎，來看看我們針對更復雜的業務邏輯我們怎么運用框架去實現它。

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