跳到主要內容

工廠模式 - 抽象工廠模式 (Abstract Factory Pattern)

        延續前一篇工廠方法模式,我們可以有多間加盟店,並且照著固定的 SOP 製作 pizza,加盟店只要專心處理 createPizza() 就好。最後還差一個步驟就能讓我們的 pizza 店更好,就是對 pizza 原料的控管。每個地區會有不同的原料,如何依照不同地區給予不同原料呢?要什麼原料就多一個工廠方法是個不錯的方法,既然會有很多原料工廠方法的話,把它們全集中在一起呢?這就是抽象工廠的概念了。我們可以先定一個抽象的原料工廠:
public interface PizzaIngredientFactory {

    // 每個原料都是一個類別,每個原料都有一個
    // 對應的方法建立該原料
    public Sauce createSauce();
    public Cheese createCheese();
    public Vaggies createVaggies();
}

        假如每個工廠的實體(子類別)都有一種通用的機制要實作,例如都要先檢查原料,清洗原料之類的,上面的例子也可以改成抽象類別。

        我們接下來就可以實作紐約風的原料工廠:
// 對於所有原料,紐約原料工廠都提供了紐約的版本
public class NYPizzaIngredientFactory implements
    PizzaIngredientFactory {

    @Override
    public Sauce createSauce()
    {
        return new NYSauce();
    }

    @Override
    public Cheese createCheese()
    {
        return new NYCheese();
    }

    @Override
    public Veggies createVeggies()
    {
        return new NYVeggies();
    }
}
        接下來要修改 Pizza,讓它只使用工廠產生出來的產料:
public abstract class Pizza {

    String name;
    Sauce sauce;
    Veggies veggies;
    Cheese cheese;

    // 把這個方法宣告成抽象,以便讓次類別
    // 使用不同工廠的原料
    abstract public void prepare();

    // 其他方法如 bake(), cut() 都不變,
    // 只有 prepare() 要改變
}
public class CheesePizza extends Pizza {

    PizzaIngredientFactory mFactory;

    // 次類別在建構時代入一個原料工廠
    public CheesePizza(PizzaIngredientFactory factory)
    {
        mFactory = factory;
    }

    // 次類別一定要實作這個方法
    @Override
    public void prepare()
    {
        // 這邊就是神奇的地方,工廠會因為建構式代入
        // 不同的工廠,而產生不同的原料
        // Pizza 不在乎是什麼工廠,只知道要原料
        // 跟工廠拿就對了
        sauce = mFactory.createSauce();
        cheese = mFactory.createCheese();
        veggies = mFactory.createVeggies();
    }
}
       最後修改一下 PizzaStore 就可以囉~
public class NYPizzaStore extneds PizzaStore {

    protected Pizza createPizza(String item)
    {
        Pizza pizza = null;

        // 因為是紐約店,所以使用紐約原料工廠
        PizzaIngredientFactory factory =
            new NYPizzaIngredientFactory();

        // 對於每一種 pizza,一律實體化一個新 pizza,
        // 並傳進該 pizza 所需的工廠,
        // 以取得對應的原料
        if(item.equals("cheese"))
        {
            pizza = new CheesePizza(factory);
            pizza.setName("New York style cheese pizza");
        }
        else if(item.equals("beef"))
        {
            pizza = new BeefPizza(factory);
            pizza.setName("New York style beef pizza");
        }

        return pizza;
    }
}
        上面的程式碼鬆綁了實際的產品,所以可以替換成不同的工廠,取得不同的行為,例如取的不是紐約風的 cheese ,而是其他地方的 cheese。

        了解觀念後,就可以來定義抽象工廠模式了:

抽象工廠模式提供了一個介面,建立相關或相依物件之家族,而不需要明確指定具象類別
Provide an interface for creating families of related or dependent objects without specifying their concrete classes.


        由類別圖可以看到,客戶的程式碼中只需涉及抽象工廠,執行其將自動使用實際的工廠。以上面的例子來看,NYPizzaStore  就是抽象工廠的客戶。

        最後來比較一下抽象工廠以及工廠方法:

        抽象工廠:主要是利用物件的合成,集結一些相關的產品,而在具象工廠使用工廠方法來實作要產出的產品。

        工廠方法:通常是由繼承來的次類別來決定要產生哪種具象產品,其主要目的是將客戶從具象型態中鬆綁。

參考資料:

        深入淺出設計模式(Head First Design Patterns)

留言

這個網誌中的熱門文章

訪問者模式 (Visitor Pattern)

        假設你設計一個系統,其中會有一些相似類別,類別中都有某些方法內容相似,但還是需要判斷目前要做事的是哪個類別才能呼叫對應的適當類別。通常遇到這種情情,在 Java 中最直接的做法就是使用 instanceof 關鍵字來判斷,如以下的簡單範例: public interface CarComponent { public void printMessage(); } public class Wheel implements CarComponent { @Override public void printMessage() { System.out.println("This is a wheel"); } // 這是 Wheel 跟 Engine 不同的方法 public void doWheel() { System.out.println("Checking wheel..."); } } public class Engine implements CarComponent { @Override public void printMessage() { System.out.println("This is a engine"); } // 這是 Wheel 跟 Engine 不同的方法 public void doEngine() { System.out.println("Testing this engine..."); } } public class Car { private List mComponents; public Car() { mComponents = new ArrayList<carcomponent>(); } // 有些時候我們還是需要針對不同類別去做不同的事情 public void setComponent(CarCompon...

責任鏈模式 (Chain of Responsibility Pattern)

        假設你的公司時常會收到不同的電子郵件如垃圾信,顧客的抱怨信,顧客的感謝信等等,而公司希望對這些不同類型的信都先用制式的罐頭信回應 (就是 不同的信件有不同的處理方式 )。當你要寫程式處理公司的電子郵件時,直接寫在一個 class 是最簡單的作法。但你勢必會用到 if/else 或 switch 等來判斷不同的信件,而這樣做有一些缺點,例如 程式複雜性增加,不夠彈性,擴充困難 等等。當你希望 多個物件 (處理信的方式) 都有機會能處理相同請求時 (新寄來的電子郵件) 時,可以考慮責任鏈模式。先介紹此模式的正式定義及類別圖: 讓多個物件都有機會可以處理請求,以避免請求的發送者和接受者之間產生耦合關係。將這些物件連成一條鏈,並沿著這條鏈傳遞請求,直到有一個物件處理這個請求為止。 Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.         從類別圖來看這個模式很單純,每個子類別都有要實作的方法來處理它們能處理的特殊請求。 當有不能處理的請求時,也能傳給下一個子類別繼續處理 。當然這邊就是由設計者自行決定要有幾個子類別來處理哪些不同的請求,以及決定這些子類別傳遞請求的順序為何。         接著來看一下套用責任鏈模式的簡單程式碼吧 // 所有處理郵件的子類別要繼承的介面 public abstract class MailHandler { // 每個處理郵件類別都要記錄下一個 // 能處理的人是誰 protected MailHandler mHandler; public MailHandler(MailHandler handler) { mHandler = handl...

狀態模式 (State Pattern)

        如果今天你要設計一台如下圖的糖果機,你會怎麼設計呢?         有上過資訊相關課程的人,應該不難從上圖聯想到 狀態圖 ,上圖中每個圓圈都是一個狀態,而每個箭頭就代表狀態的轉換。有了這個概念後,把它轉成程式就不難了: public class CandyMachine { // 以下四個值表示糖果機會用到的狀態 final static int SOLD_OUT = 0; final static int NO_COIN = 1; final static int HAS_COIN = 2; final static int SOLD = 3; // 需要有一個變數來記錄目前的狀態 // 初始設為賣完, 因為一開始機器裡沒糖果 int mState = SOLD_OUT; // 也要有另一個變數記錄目前剩多少顆糖果 int mCount = 0; public CandyMachine(int count) { mCount = count; // 機器內有糖果的話就跳到沒投錢的狀態, // 表示糖果機在等人投錢 if(mCount > 0) { mState = NO_COIN; } } // 當投錢時會執行這個方法 public void insertCoin() { if(mState == HAS_COIN) { System.out.println("You can't insert another coin"); } else if(mState == NO_COIN) { mState == HAS_COIN; System.out.println("You inserted a coin"); } ...