Simple Factory Pattern (簡單工廠模式)

特性：

• 把類的實例化工作，集中到一個「工廠類」去處理，亦即將 new instance 的工作，都交給一個「工廠」去處理，而不要分散寫在各個類中。
• 客戶端程序，與創建實例 (對象) 的工作必須隔離，亦即「解耦」，客戶端程序只要專注于自己的業務邏輯。適用于客戶端程序在開發過程中，尚無法預知要創建的具體類型。
• 產品具體的實現能和客戶端隔離，便于事后抽換。

Simple Factory Pattern (簡單工廠模式)、Factory Method Pattern (工廠方法模式)，在實作的代碼中，有時很難明確去界定此二者。Simple Factory 的特性，如前所述，在于將創建實例 (new instance) 的工作，集中由特定的一個「工廠類」來處理，避免寫在各個類中，以方便日后添加新功能，和修改既有的功能。

如下「進口水果」的代碼，為 O'Reilly 的「C# 3.0 Design Patterns」這本書籍 [1] 第五章的 Factory Method 示例。乍看之下，我覺得它比較像 Simple Factory Pattern，因其仍將創建實例，和部分邏輯判斷的工作，都集中在一個 工廠類 (Creator1 類) 去處理，導致日后要添加新功能 (多引進一個國家的水果)，或要修改判斷「進口月份」的邏輯時，仍要修改 server-side 的這個「工廠類」，而無法只修改 client-side 的 Page_Load 方法，違背了「開放-封閉」原則。

但這個示例，要實例化哪個類型，是由「工廠類」以及客戶端 (水果店主人) 的 Page_Load 方法，共同決定的。透過 IProduct 接口，看似隔離了客戶端程序、具體 Product 的依賴關系，但客戶端程序仍有創建對象的決定權，因此其與創建實例 (對象) 的工作并未真正隔離。

SimpleFactory.aspx.cs
using System;

//這個示例事實上算是一個 Factory Method Pattern
public partial class SimpleFactory : System.Web.UI.Page
{
    //客戶端調用(Client-Side)。這個示例的客戶端，如同一間水果店的店主人。
    protected void Page_Load(object sender, EventArgs e)
    {
        Creator1 c = new Creator1();    //工廠類實體
        IProduct product;

        //由客戶端決定要具體實例化哪些類型。
        //但此示例的特點，為客戶端不需要知道產品類型。
        for (int i = 1; i <= 12; i++)
        {
            //客戶端不需要知道產品類型。把創建哪種具體產品的決定，委托給了工廠方法
            product = c.factoryMethod(i);
            Response.Write("水果進口, " + i + "月: " + product.shipFrom() + "
");
        }
    }

    //這個示例，要實例化哪個類型，是由「工廠類」以及 Client-Side 的 Page_Load() 方法，共同決定的。
    //透過 IProduct 接口，看似隔離了客戶端程序、具體 Product 的依賴關系，
    //但客戶端程序仍有創建對象的決定權，因此其與創建實體 (對象) 的工作并未真正隔離。
    
    //即使日后修改了某個子類 shipFrom() 里的實作方式，對客戶端不會有影響，
    //客戶端只要知道如何操作 shipFrom() 去進口水果即可。
}

//所有的產品，必須實現這個接口。如此一來，先建立一種「契約」，
//以后要增添、修改產品時，就可由這個接口(或抽象類)來操作。
interface IProduct
{
    //隱藏實現細節。
    //事前不知道要創建哪種類的實體(產品)，延至 Creator1 類或「客戶端」中實現。
    string shipFrom();
}


//單一職責原則，每一個類都只負責一件具體的事情。
// 臺灣的水果供貨商。
class ProductA : IProduct
{
    public string shipFrom()
    {
        return " from 臺灣";
    }
}

//單一職責原則，每一個類都只負責一件具體的事情。
// 美國的水果供貨商。
class ProductB : IProduct
{
    public string shipFrom()
    {
        return "from 美國";
    }
}

//單一職責原則，每一個類都只負責一件具體的事情
class DefaultProduct : IProduct
{
    public string shipFrom()
    {
        return "不進口";
    }
}

//工廠類 (水果采購人員)，負責創建實體(采購水果)。只有這個類，知道如何創建這些產品的邏輯
class Creator1
{
    //日后若引進新產品 (多引進一個國家的水果)、修改舊產品，可集中在這里抽換；
    //但缺點亦如是，亦即仍需修改這里的 Server-Side 代碼，必須修改此一工廠類。

    //此處做法，偏向「簡單工廠模式」的實體創建。
    public IProduct factoryMethod(int month)
    {
        if (month >= 4 && month <= 11)
            return new ProductA();
        else
            if (month == 1 || month == 2 || month == 12)
                return new ProductB();
            else
                return new DefaultProduct();
    }
}

//另一個工廠類
//class Creator2
//{
//    public IProduct factoryMethod(int month, int day)
//    {
//        不同的水果進口方式
//    }
//}

/* 
執行結果:

水果進口, 1月: from 美國
水果進口, 2月: from 美國
水果進口, 3月: 不進口
水果進口, 4月: from 臺灣
水果進口, 5月: from 臺灣
水果進口, 6月: from 臺灣
水果進口, 7月: from 臺灣
水果進口, 8月: from 臺灣
水果進口, 9月: from 臺灣
水果進口, 10月: from 臺灣
水果進口, 11月: from 臺灣
水果進口, 12月: from 美國

*/
//

圖 1　Sybase PowerDesigner 繪制的「進口水果」示例的 Class Diagram

--------------------------------------------------------

Factory Method Pattern (工廠方法模式)

特性：

• 由子類來決定要具體實例化哪種類型。這些子類實現了某個共通的接口，或繼承自某個共用的抽象類。
• 讓一個類的實例化，延遲到其子類。
• 由客戶端程序，來決定要創建哪些工廠類型。

上述特性的第一點，所提到的子類，如同下方示例里的「博派Factory」類、「狂派Factory」類。

上述特性的第三點，Factory Method 和 Simple Factory 剛好相反。Factory Method 把 Simple Factory 中「工廠類」的邏輯判斷，移到客戶端來進行。日后若想添加、修改功能，原本 Simple Factory 是要修改「工廠類」的，但 Factory Method 變成要修改客戶端程序，但也改善了 Simple Factory 的缺點，亦即不用再冒險修改原本已可正常工作的 server-side「工廠類」，而只要改 client-side 的 Page_Load 方法，符合了「開放-封閉」原則。

Factory Method 的實現方式有很多種，但原則為，先用一個抽象類或接口，當作定義 (如下方示例的 IFactory)，并留下抽象方法而不實作 (如下方示例的 createTransformer 方法)。要延遲到子類，由子類來決定要實例化哪種類型 (如下方示例的「博派Factory」和「狂派Factory」這兩個子類)。

FactoryMethod.aspx.cs
using System;

public partial class FactoryMethod : System.Web.UI.Page
{
    //客戶端調用(Client-Side)。
    protected void Page_Load(object sender, EventArgs e)
    {
        //客戶端程序調用的時候，只要改右側創建實體的類型即可
        IFactory factory1 = new 博派Factory();
        變形金剛 擎天柱 = factory1.createTransformer();
        擎天柱.transformCar();

        //把職責委托給平行層次中的子類
        IFactory factory2 = new 狂派Factory();
        變形金剛 威震天 = factory2.createTransformer();
        威震天.transformAirplane();
    }
}

//IProduct
class 變形金剛
{
    public virtual void transformCar()
    {
        Console.WriteLine("變汽車");
    }

    public virtual void transformAirplane()
    {
        Console.WriteLine("變飛機");
    }

    public virtual void transformAnimal()
    {
        Console.WriteLine("變動物");
    }
}

//IProduct 的子類
class 博派 : 變形金剛
{ }

//IProduct 的子類
class 狂派 : 變形金剛
{ }


//變形金剛工廠 (亦可用抽象類)
interface IFactory
{
    //隱藏實現細節。
    //事前不知道要創建哪種變形金剛，延至「客戶端」中實現。
    變形金剛 createTransformer();
}

//博派的工廠 (由此種子類來決定具體實例化哪種類型)
class 博派Factory : IFactory
{
    public 變形金剛 createTransformer()
    {
        return new 博派();
    }
}

//狂派的工廠 (由此種子類來決定具體實例化哪種類型)
class 狂派Factory : IFactory
{
    public 變形金剛 createTransformer()
    {
        return new 狂派();
    }
}

//以后引進新產品 (墮落金剛) 時，我們不需要冒險修改既有的「工廠類」，而只要添加新的產品類、新的工廠類，
//最后由 IFactory 的子類，以及客戶端程序 (Page_Load 方法)，來決定要創建哪些具體類型；
//整個架構變成只有「擴展」的變化，而不再有「修改」的變化。

//若要修改舊功能，如狂派類，要加入組合成「大力神」的功能時，也只需要修改既有的「狂派」類。

圖 2　Sybase PowerDesigner 繪制的「變形金剛 - 工廠方法模式」Class Diagram

以后引進新產品 (墮落金剛) 時，我們不需要冒險修改既有的「工廠類」，而只要添加新的「產品類」、新的「工廠類」，最后由 IFactory 的子類，以及客戶端程序 (Page_Load 方法)，來決定要創建哪些具體類型；整個架構變成只有「擴展」的變化，而不再有「修改」的變化。此外，若要修改舊功能，如：「狂派」類，要加入組合成「大力神」的功能時，也只需要修改既有的「狂派」類即可。

Factory Method Pattern 并無固定的實現方式，上述兩個示例，僅為其中一種實現方式，若參考一些 Java 的論壇、書籍、文件，還能找到更多的變化應用 [7], [8]。