Simple Factory Pattern (簡單工廠模式)

特性：

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

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

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

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

using System;

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

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

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

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


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

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

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

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

    //此處做法，偏向「簡單工廠模式」的實體創(chuàng)建。
    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)
//    {
//        不同的水果進口方式
//    }
//}

/* 
執(zhí)行結(jié)果:

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

*/
//

NET技術(shù)：C# Design Patterns (1) - Factory Method，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。