簡單工廠模式是類的創(chuàng)建模式，又叫做靜態(tài)工廠方法模式。簡單工廠模式由一個(gè)工廠對象決定生產(chǎn)出哪一種產(chǎn)品類的實(shí)例。

    為什么要使用簡單工廠模式

    原因很簡單：解耦。

    A對象如果要調(diào)用B對象，最簡單的做法就是直接new一個(gè)B出來。這么做有一個(gè)問題，假如C類和B類實(shí)現(xiàn)了同一個(gè)接口/繼承自同一個(gè)類，系統(tǒng)需要把B類修改成C類，程序不得不重寫A類代碼。如果程序中有100個(gè)地方new了B對象，那么就要修改100處。

    這就是典型的代碼耦合度太高導(dǎo)致的"牽一發(fā)動(dòng)全身"。所以，有一個(gè)辦法就是寫一個(gè)工廠IFactory，A與IFactory耦合，修改一下，讓所有的類都實(shí)現(xiàn)C接口并且IFactory生產(chǎn)出C的實(shí)例就可以了。

    簡單工廠模式示例

    以水果為例：

    有兩個(gè)子類蘋果和葡萄：

    有一個(gè)園丁，專門負(fù)責(zé)生產(chǎn)出各種水果：

    想要什么水果就問園丁拿就好了：

    程序這么寫優(yōu)點(diǎn)就出來了：

    1.用戶不自己去生產(chǎn)產(chǎn)品，只需要負(fù)責(zé)去拿自己需要的東西就好了，這樣用戶-->產(chǎn)品之間的耦合度就降低了

    2.代碼模塊職責(zé)更明確了，有專門消費(fèi)的模塊、有專門生產(chǎn)的模塊

    改進(jìn)

    上面的代碼雖然實(shí)現(xiàn)了用戶-->產(chǎn)品之間的分離，但還是有一個(gè)問題，工廠并不知道有多少種產(chǎn)品，所以每一次新增產(chǎn)品的時(shí)候，都需要新增elseif分支，這樣是不是不便呢？所以我們又想了一個(gè)辦法，就是反射，園丁可以這么修改：

    調(diào)用的地方可以寫成：

    當(dāng)然，這么寫其實(shí)也有一點(diǎn)點(diǎn)問題，假如有一天我的項(xiàng)目想進(jìn)行一個(gè)重構(gòu)，重整類路徑，包路徑，比方說生產(chǎn)Apple的地方有100處，豈不是要修改100處？當(dāng)然不用，有以下三種方法推薦：

    1.寫一個(gè)接口FruitPath，里面定義常量：

    2.寫一個(gè)Fruit.properties文件，里面定義水果和類路徑的對應(yīng)關(guān)系：

    3.寫一個(gè)Fruit.xml文件，里面定義水果和類路徑的對應(yīng)關(guān)系：

    第一種方式不說了，第二種方式.properties可以用Java自帶的Properties類來解析，第三種方式.xml可以用DOM4J來解析。這樣，假設(shè)我以后要修改水果的路徑，修改一個(gè)文件就可以了。

    從設(shè)計(jì)模式的角度講，這么修改也有很大的優(yōu)點(diǎn)?，F(xiàn)在不管我新增還是刪除水果，園?。惞S）都不用變了，只需要告訴工廠我需要哪種水果就夠了，工廠自然會給調(diào)用者返回。這種寫法，也是Spring的基礎(chǔ)。

    最后說一點(diǎn)，希望大家明白，簡單工廠模式或者說工廠模式的關(guān)注點(diǎn)并不在于在工廠中是如何生產(chǎn)出來需要的類的，而在于將創(chuàng)建產(chǎn)品與消費(fèi)產(chǎn)品分離。前面使用過if...elseif...else、反射，除了這些方法，還可以有別的方法可以創(chuàng)建產(chǎn)品，比如傳入一個(gè)具體產(chǎn)品的標(biāo)識，根據(jù)這個(gè)標(biāo)識去數(shù)據(jù)庫里面查詢。

    簡單工廠模式在Java中的應(yīng)用及解讀

    以后每一篇文章盡可能地介紹設(shè)計(jì)模式在Java中的應(yīng)用，因?yàn)槲艺J(rèn)為不是每種設(shè)計(jì)模式開發(fā)者都有機(jī)會可以用到，但是能在原有代碼中敏銳地看出這是一種什么設(shè)計(jì)模式，至少能說明對這種設(shè)計(jì)模式是理解了。這里講一下JDK中的簡單工廠模式。

    JDK中的簡單工廠模式有很多應(yīng)用，比較典型的比如線程池，具體可以參見Java多線程18：線程池。我們使用線程池的時(shí)候，可以使用ThreadPoolExecutor，根據(jù)自己的喜好傳入corePoolSize、maximumPoolSize、keepAliveTimem、unit、workQueue、threadFactory、handler這幾個(gè)參數(shù)，new出一個(gè)指定的ThreadPoolExecutor出來。

    JDK給開發(fā)者提供了Executors這個(gè)類，可以讓用戶產(chǎn)生ThreadPoolExecutor和使用ThreadPoolExecutor分離開，比如可以讓Executors提供一個(gè)單線程的線程池Executors.newSingleThreadExecutor()、讓Executors提供一個(gè)無界線程池Executors.newCachedThreadPool()等，這樣，開發(fā)者可以不用關(guān)心線程池是如何去實(shí)現(xiàn)的，直接使用Executors方法提供給開發(fā)者的ThreadPoolExecutor就可以了。

    工廠模式的優(yōu)缺點(diǎn)

    優(yōu)點(diǎn)：

    1.簡單優(yōu)化了軟件體系結(jié)構(gòu)，明確了各自功能模塊的職責(zé)和權(quán)利

    2.通過工廠類，外界不需要直接創(chuàng)建具體產(chǎn)品對象，只需要負(fù)責(zé)消費(fèi)，不需要關(guān)心內(nèi)部如何創(chuàng)建對象

    缺點(diǎn)：

    1.改進(jìn)前的簡單工廠模式全部創(chuàng)建邏輯都集中在一個(gè)工廠類中，能創(chuàng)建的類只能是考慮到的，如果需要添加新的類，就必須改變工廠類了

    2.改進(jìn)前的簡單工廠模式隨著具體產(chǎn)品的不斷增多，可能會出現(xiàn)共產(chǎn)類根據(jù)不同條件創(chuàng)建不同實(shí)例的需求，這種對條件的判斷和對具體產(chǎn)品類型的判斷交錯(cuò)在一起，很難避免功能模塊的蔓延，對系統(tǒng)的維護(hù)和擴(kuò)展不利

    3.改進(jìn)后的簡單工廠模式主要是使用反射效率會低一些

　以上就是動(dòng)力節(jié)點(diǎn)java培訓(xùn)機(jī)構(gòu)的小編針對“簡單工廠模式，Java工廠設(shè)計(jì)模式”的內(nèi)容進(jìn)行的回答，希望對大家有所幫助，如有疑問，請?jiān)诰€咨詢，有專業(yè)老師隨時(shí)為你服務(wù)。