一、引言

在面向物件程式設計中, 最通常的方法是一個new操作符產生一個物件例項,new操作符就是用來構造物件例項的。但是在一些情況下, new操作符直接生成物件會帶來一些問題。舉例來說, 許多型別物件的創造需要一系列的步驟: 你可能需要計算或取得物件的初始設定; 選擇生成哪個子物件例項; 或在生成你需要的物件之前必須先生成一些輔助功能的物件。 在這些情況,新物件的建立就是一個 “過程”，不僅是一個操作，像一部大機器中的一個齒輪傳動。
　　
模式的問題：你如何能輕鬆方便地構造物件例項，而不必關心構造物件例項的細節和複雜過程呢？

解決方案：建立一個工廠來建立物件

1）還沒有工廠時代：假如還沒有工業革命，如果一個客戶要一款寶馬車,一般的做法是客戶去建立一款寶馬車，然後拿來用。
2）簡單工廠模式：後來出現工業革命。使用者不用去建立寶馬車。因為客戶有一個工廠來幫他建立寶馬.想要什麼車，這個工廠就可以建。比如想要320i系列車。工廠就建立這個系列的車。即工廠可以建立產品。
3）工廠方法模式時代：為了滿足客戶，寶馬車系列越來越多，如320i，523i,30li等系列一個工廠無法建立所有的寶馬系列。於是由單獨分出來多個具體的工廠。每個具體工廠建立一種系列。即具體工廠類只能建立一個具體產品。但是寶馬工廠還是個抽象。你需要指定某個具體的工廠才能生產車出來。
4）抽象工廠模式時代：隨著客戶的要求越來越高，寶馬車必須配置空調。於是這個工廠開始生產寶馬車和需要的空調。

最終是客戶只要對寶馬的銷售員說：我要523i空調車，銷售員就直接給他523i空調車了。而不用自己去建立523i空調車寶馬車.

這就是工廠模式。

二、工廠模式的介紹
　
工廠模式主要是為建立物件提供過渡介面，以便將建立物件的具體過程遮蔽隔離起來，達到提高靈活性的目的。
工廠模式可以分為三類：
1）簡單工廠模式（Simple Factory）
2）工廠方法模式（Factory Method）
3）抽象工廠模式（Abstract Factory）
這三種模式從上到下逐步抽象，並且更具一般性。
GOF在《設計模式》一書中將工廠模式分為兩類：工廠方法模式（Factory Method）與抽象工廠模式（Abstract Factory）。

將簡單工廠模式（Simple Factory）看為工廠方法模式的一種特例，兩者歸為一類。

工廠方法模式：
一個抽象產品類，可以派生出多個具體產品類。
一個抽象工廠類，可以派生出多個具體工廠類。
每個具體工廠類只能建立一個具體產品類的例項。
抽象工廠模式：
多個抽象產品類，每個抽象產品類可以派生出多個具體產品類。
一個抽象工廠類，可以派生出多個具體工廠類。
每個具體工廠類可以建立多個具體產品類的例項。
區別：
工廠方法模式只有一個抽象產品類，而抽象工廠模式有多個。
工廠方法模式的具體工廠類只能建立一個具體產品類的例項，而抽象工廠模式可以建立多個。

四、簡單工廠模式 　
說到簡單工廠，自然的第一個疑問當然就是什麼是簡單工廠模式了？ 在現實生活中工廠是負責生產產品的,同樣在設計模式中,簡單工廠模式我們也可以理解為負責生產物件的一個類

建立一個工廠（一個函式或一個類方法）來製造新的物件。

分佈說明引子：從無到有。客戶自己建立寶馬車，然後拿來用。

public class BMW320 
{
    public BMW320()
    {
        Console.WriteLine("製造-->BMW320");
    }
}

public class BMW523 
{
    public BMW523()
    {
        Console.WriteLine("製造-->BMW523");
    }
}

public class Customer {
    public static void main(String[] args) 
    {
        BMW320 bmw320 = new BMW320();
        BMW523 bmw523 = new BMW523();
    }
}

客戶需要知道怎麼去建立一款車,客戶和車就緊密耦合在一起了.為了降低耦合,就出現了工廠類,把建立寶馬的操作細節都放到了工廠裡面去,客戶直接使用工廠的建立工廠方法,傳入想要的寶馬車型號就行了,而不必去知道建立的細節.這就是工業革命了：簡單工廠模式

即我們建立一個工廠類方法來製造新的物件。

public class Factory 
{
    public BMW CreateBMW(int type)
    {
        switch (type)
        {
            case 320:
                return new BMW320();

            case 523:
                return new BMW523();

            default:
                break;
        }
        return null;
   }
}

public class Customer 
{
    public static void main(String[] args) 
    {
        Factory factory = new Factory();
        BMW bmw320 = factory.CreateBMW(320);
        BMW bmw523 = factory.CreateBMW(523);
    }
}

三、總結
　　看完簡單工廠模式的實現之後，你和你的小夥伴們肯定會有這樣的疑惑（因為我學習的時候也有）——這樣我們只是把變化移到了工廠類中罷了，好像沒有變化的問題，因為如果新增其他車系時，此時我們還是需要修改工廠類中的方法（也就是多加case語句，沒應用簡單工廠模式之前，修改的是客戶類）。我首先要說：你和你的小夥伴很對，這個就是簡單工廠模式的缺點所在（這個缺點後面介紹的工廠方法可以很好地解決），然而，簡單工廠模式與之前的實現也有它的優點：
1）解決了客戶端直接依賴於具體物件的問題，客戶端可以消除直接建立物件的責任，而僅僅是消費產品。
2）實現了對責任的分割。
3）起到了程式碼複用的作用，因為在沒有工廠類時，所有的客戶呼叫都有直接new，然而有了簡單工廠之後，此時簡單工廠的造車方法就讓所有客戶共用了。（同時這點也是簡單工廠方法的缺點——因為工廠類集中了所有產品建立邏輯，一旦不能正常工作，整個系統都會受到影響，也沒什麼不好理解的，就如事物都有兩面性一樣道理）

雖然上面已經介紹了簡單工廠模式的缺點，下面還是總結下簡單工廠模式的缺點：
1）工廠類集中了所有產品建立邏輯，一旦不能正常工作，整個系統都會受到影響（通俗地意思就是：一旦工廠類罷工了，使用這個工廠的客戶就沒有車可以使用了）
2）系統擴充套件困難，一旦新增新產品就不得不修改工廠邏輯，這樣就會造成工廠邏輯過於複雜。

瞭解了簡單工廠模式之後的優缺點之後，我們之後就可以知道簡單工廠的應用場景了：
1）當工廠類負責建立的物件比較少時可以考慮使用簡單工廠模式
2）客戶如果只知道傳入工廠類的引數，對於如何建立物件的邏輯不關心時可以考慮使用簡單工廠模式

簡單工廠模式又稱靜態工廠方法模式。從命名上就可以看出這個模式一定很簡單。
它存在的目的很簡單：定義一個用於建立物件的介面。
先來看看它的組成：
1) 工廠類角色：這是本模式的核心，含有一定的商業邏輯和判斷邏輯，用來建立產品
2) 抽象產品角色：它一般是具體產品繼承的父類或者實現的介面。
3) 具體產品角色：工廠類所建立的物件就是此角色的例項。

下面我們從開閉原則（對擴充套件開放；對修改封閉）上來分析下簡單工廠模式。當客戶不再滿足現有的車型號的時候，想要一種速度快的新型車，只要這種車符合抽象產品制定的合同，那麼只要通知工廠類知道就可以被客戶使用了。所以對產品部分來說，它是符合開閉原則的；但是工廠部分好像不太理想，因為每增加一種新型車，都要在工廠類中增加相應的建立業務邏輯（createBMW(int type)方法需要新增case），這顯然是違背開閉原則的。可想而知對於新產品的加入，工廠類是很被動的。對於這樣的工廠類，我們稱它為全能類或者上帝類。
我們舉的例子是最簡單的情況，而在實際應用中，很可能產品是一個多層次的樹狀結構。由於簡單工廠模式中只有一個工廠類來對應這些產品，所以這可能會把我們的上帝累壞了，也累壞了我們這些程式設計師。
於是工廠方法模式作為救世主出現了。 工廠類定義成了介面,而每新增的車種型別,就增加該車種型別對應工廠類的實現,這樣工廠的設計就可以擴充套件了,而不必去修改原來的程式碼。