設計模式-簡單工廠-建立型模式

在設計模式當中有三大工廠，分别是

簡單工廠

、

抽象工廠

工廠方法

這三種建立執行個體的設計模式，這裡先從簡單工廠将其，從名字就可以看出這是這三種工廠模式當中最為簡單的一種實作。

簡單工廠一般由以下幾個對象組成：

對象	作用
工廠類	負責建立産品
抽象産品類	工廠建立出來的産品抽象
具體産品類	繼承自抽象産品類，具體的産品功能

那麼我們為什麼不直接 new 一個對象來執行操作呢？如果有以下代碼:

public class BusinessClass
{
    public void Process()
    {
        Car _car = new Car();
        _car.Run();
    }
}
           

這麼寫的話，一旦我們業務邏輯發生變化，我不想建立 Car 對象了，我想建立一個 AirPlane 對象，他也具有 Run 方法，這個時候這種寫法就很尴尬了，我需要在後面加一個

AirPlane air = new AirPlane()

然後再 Run。

而工廠模式則将建立與使用分離開來，使用者不用關心怎麼建立的，隻需要告訴工廠你需要哪種類型的對象，我給你建立好，你直接調用即可。乍一看來沒有什麼改變，但之前直接 new 對象的方式則造成

BusinessClass

對于 Car 等對象造成了一種依賴關系。

換句話說，如果按照上面那種方式書寫，BusinessClass 則是依賴于 Car 對象的，而簡單工廠則是降低對象之間的耦合度(依賴)的。

在上面的例子中，我們要封裝他們的改變，他們之間改變的地方在于執行個體的建立，那麼我們封裝之後就由工廠來進行建立，便有以下代碼：

抽象産品類：

public abstract class Product
{
    void Run();
}
           

再有一個工廠類:

public static class Factory
{
    public static Product CreateInstance(string type)
    {
        switch(type)
        {
            case "Car":
                return new Car();
            case "AirPlane":
                return new AirPlane();
            default:
                return null;
        }
    }
}
           

有了工廠類，我們再來定義兩個具體的實作類:

public class Car : Product
{
    public override void Run()
    {
        Console.WriteLine("這是汽車");
    }
}
public class AirPlane : Product
{
    public override void Run()
    {
        Console.WriteLine("這是飛機");
    }
}
           

之後我們再改一下剛才的 BusinessClass:

public class BusinessClass
{
    public void Process()
    {
        Product car = Factory.CreateInstance("Car");
        car.Run();
        Product air = Factory.CreateInstance("AirPlane");
        air.Run();
    }
}
           

這裡其實我們也察覺了，如果我們每增加一個具體的産品，那麼我們的工廠方法邏輯也會越來越臃腫，而且工廠類一點不能正常運作，就

會造成災難性的後果。

簡單工廠僅适用于工廠類負責建立的對象，較少的話對于工廠類的邏輯也不會太複雜。而且使用者僅需要知道傳入工廠類的參數即可建立對象，使用者不需要具體的建立過程。