哈嘍！今天開始，慢慢和大家一起分享我學(xué)習(xí)和理解設(shè)計模式的歷程。

(資料圖片僅供參考)

設(shè)計模式（Design Pattern）是前輩們對代碼開發(fā)經(jīng)驗的總結(jié)，是解決特定問題的一系列套路。它不是語法規(guī)定，而是一套用來提高代碼可復(fù)用性、可維護(hù)性、可讀性、穩(wěn)健性以及安全性的解決方案。

1995 年，GoF（Gang of Four，四人組/四人幫）合作出版了《設(shè)計模式：可復(fù)用面向?qū)ο筌浖幕A(chǔ)》一書，共收錄了 23 種設(shè)計模式，從此樹立了軟件設(shè)計模式領(lǐng)域的里程碑，人稱「GoF設(shè)計模式」。

讓我們從創(chuàng)建型模式開始。先來說說工廠模式！

工廠模式是一種創(chuàng)建型的面向?qū)ο笤O(shè)計模式，目的將創(chuàng)建對象的具體過程包裝起來，從而達(dá)到更高的靈活性。工廠模式的本質(zhì)就是用工廠方法代替 new 操作創(chuàng)建一種實例化對象的方式，以提供一種方便地創(chuàng)建有同種類型接口的產(chǎn)品的復(fù)雜對象。

簡單說來：我們不new對象了，讓工廠方法來生產(chǎn)對象

工廠模式可以細(xì)分如下三類：

簡單工廠模式（Simple Factory）

工廠方法模式（Factory Method）

抽象工廠模式（Abstract Factory）

今天來看下工廠模式之簡單工廠模式

簡單工廠模式（Simple Factory）又叫做靜態(tài)工廠方法（Static Factory Method）模式，但不屬于 23 種 GOF 設(shè)計模式之一。

簡單工廠模式的實質(zhì)是由一個工廠類根據(jù)傳入的參數(shù)，動態(tài)決定應(yīng)該創(chuàng)建哪一個產(chǎn)品類（這些產(chǎn)品類繼承自一個父類或接口）的實例。

從上面的描述中，我們可以抽象出這么幾個角色：

產(chǎn)品抽象類：

public interface Phone {  public String info();}

產(chǎn)品類（具體實現(xiàn)類）：

public class HuaweiPhone implements Phone{  @Override  public String info() {    return "我是手機(jī)華為";  }}

public class ApplePhone implements Phone{  @Override  public String info() {    return "我是蘋果手機(jī)";  }}

工廠類

public class PhoneFactory{  public static Phone createPhone(String name){    Phone p = null;    switch(type) {      case "huawei":        p = new HuaweiPhone();        break;      case "apple":        p = new ApplePhone();        break;      default:        throw new UnsupportedOperationException("不支持該操作");    }    return p;  }}

讓我們來測試下：

public class Test {  public static void main(String[] args) {    SimpleFactory PhoneFactory = new PhoneFactory();     Phone phone1 = PhoneFactory.createPhone("huawei");    System.out.println(phone1.info());    Phone phone2 = PhoneFactory.createPhone("apple");    System.out.println(phone2.info());  }}

輸出：

我是華為手機(jī)

我是蘋果手機(jī)

給什么條件，就創(chuàng)建什么類型的實例，就這么簡單。不愧簡單工廠模式的名號。

上面的例子中，我們是知道該工廠能創(chuàng)建華為手機(jī)和蘋果手機(jī)。所有我們在測試的時候，也只創(chuàng)建了這兩個實例。

如果現(xiàn)在要創(chuàng)建一個”小米手機(jī)“，那這個工廠就沒法創(chuàng)建出來了

小伙伴可能會說，那就在switch...case...中再增加一個case "xiaomi"吧！

嗯嗯，這個辦法能解決”小米手機(jī)“的創(chuàng)建問題。但如果后面我們還要陸續(xù)創(chuàng)建”oppo手機(jī)“”三星手機(jī)“...

如果延續(xù)這種方法，我們每增加一種手機(jī)的創(chuàng)建，就要添加一次case，也就要每次都修改 PhoneFactory 類。這顯然是違背了【開閉原則】。同時，這樣的工廠類太被動了。

那怎么解決這個問題呢？我們下期再分享。

工廠類是整個簡單工廠模式的關(guān)鍵。包含了必要的邏輯判斷，根據(jù)外界給定的信息，決定究竟應(yīng)該創(chuàng)建哪個具體類的對象。

通過使用工廠類，外界可以從直接創(chuàng)建具體產(chǎn)品對象的尷尬局面擺脫出來（不用直接new對象了），僅僅需要負(fù)責(zé)“消費”對象就可以了。而不必管這些對象究竟如何創(chuàng)建及如何組織的。明確了各自的職責(zé)和權(quán)利，有利于整個軟件體系結(jié)構(gòu)的優(yōu)化。

但是由于工廠類集中了所有實例的創(chuàng)建邏輯，違反了高內(nèi)聚責(zé)任分配原則，將全部創(chuàng)建邏輯集中到了一個工廠類中；它所能創(chuàng)建的類只能是事先考慮到的，如果需要添加新的類，則就需要改變工廠類了。

當(dāng)系統(tǒng)中的具體產(chǎn)品類不斷增多時候，可能會出現(xiàn)要求工廠類根據(jù)不同條件創(chuàng)建不同實例的需求．這種對條件的判斷和對具體產(chǎn)品類型的判斷交錯在一起，很難避免模塊功能的蔓延，對系統(tǒng)的維護(hù)和擴(kuò)展非常不利；

一句話：雖然簡單工廠模式實現(xiàn)了對象的創(chuàng)建和對象的使用分離，但增加新的具體產(chǎn)品需要修改工廠類的判斷邏輯代碼，違背開閉原則。

為了解決這些缺點，就有了工廠方法模式。

我下回再講工廠方法，今天先到這里了！