工廠模式 - 工廠方法模式 (Factory Method Pattern)

        延續前一篇簡單工廠的 Pizza 店，當你想要開放加盟時，加盟店可能因為不同地區要有不同的口味，如要用紐約風味或芝加哥風味時，要怎麼做呢？假如用 SimplePizzaFactory 的方式，寫出不同的工廠，如 NYPizzaFactory，ChicagoPizzaFactory，這樣各地加盟店都能有適合的工廠可以使用，但是其他部份可能使用加盟店自己的流程，如切片方式，裝盒方式不同。因為工廠只管產出 Pizza，並不負責後續的處理。當你想要對 Pizza 有多一些品質控管時，應該如何做呢？

        其實要改變的程式不多，只要把 createPizza() 放回 PizzaStore 中，並把這個方法設定為抽象方法，然後為每個不同地區的加盟店，建立一個 PizzaStore 次類別：

// 記得要設定為抽象類別
public abstract class PizzaStore {

    // 為了處理訂單一致，要讓子類別不能修改此方法
    final public Pizza orderPizza(String type)
    {
        Pizza pizza;

        // createPizza() 從工廠移回 PizzaStroe
        pizza = createPizza(String type);

        pizza.prepare();
        pizza.bake();
        pizza.cut();
        pizza.box();

        return pizza;
    }

    // 把工廠要做的事改成這個抽象工廠方法
    abstract Pizza createPizza(String type);
}

        orderPizza() 是被宣告在抽象的 PizzaStore 內，因此也不知道次類別如何實際製作 Pizza。而當 orderPizza() 呼叫 createPizza() 時，某個具象的次類別 PizzaStore 會負責建立 Pizza。因此我們的紐約風 Pizza 店可以這樣寫：

// NYPizzaStore 也擁有 orderPizza() 及其他方法
public class NYPizzaStore extends PizzaStore {

    // 只要是 PizzaStore 的次類別就一定要實作此方法
    Pizza createPizza(String item)
    {
        if(item.equals("cheese"))
        {
            return new NYCheesePizza();
        }
        else if(item.equals("beef"))
        {
            return new NYBeefPizza();
        }
        else
        {
            return null;
        }
    }
}

        從上面兩段程式碼可以看到，實體化 Pizza 的工作被移到了一個方法，而這個方法就如同是前一篇的工廠。這樣的作法可以將客戶程式碼 (也就是父類別中的方法，如 orderPizza ) 和實際建立產品 (如 Pizza ) 的程式碼分隔開來。在此我們都省略了 Pizza 跟所有 Pizza 次類別的程式碼，我們一樣可以建立抽象的 Pizza 類別，並定義一些方法，如 bake()，cut()。而 Pizza 次類別需要的話也可以覆寫這些已定義好的方法。

        以下就是工廠方法模式的正式定義：

工廠方法模式定義了一個建立物件的介面，但由次類別決定要實體化的類別為何者。工廠方法讓類別把實體化的動作，交由次類別進行

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

        工廠方法模式可以封裝「具象型態的實體化」。用類別圖來看，抽象的 Creator 提供一個方法能建立物件，這樣的方法就叫做「工廠方法」。在 Creator 中的其他方法都能使用工廠方法所製造出來的產品，但只有次類別真正實作這個方法，產生出物件。

        另外要注意的是，定義中的「決定」並不是指此模式允許次類別本身在執行期做決定，而是指：在寫 Creator 類別時，不需要知道實際建立的產品是什麼。選擇使用哪個次類別，自然就決定要建立的產品為何。

        最後來討論物件的相依性。以最一開始的 PizzaStore 來看，createPizza() 裡面包含了要建立所有 pizza 的 if 判斷式，未來若是某個 pizza 次類別修改了，或是要新增新的 Pizza，PizzaStore 也要跟著修改，這樣的關係就像是 PizzaStore 「依賴」 Pizza 的實作方式。而以下就是說明減少依賴具象類別的設計準則：顛覆依賴守則 (Dependency Inversion Principle)

依賴抽象類別，不要依賴具象類別

        這守則說明了不要讓高階元件依賴低階元件。高階元件指的是由其他低階元件定義其類別的行為，如 PizzaStore prepare，bake，cut Pizza 物件; 而 Pizza 本身就是屬於低階物件。此守則也說明不管高階低階元件，都應該相依於抽象類別。以此篇文章的 PizzaStore 加上工廠方法模式就能發現，PizzaStore 依賴 Pizza 這個「抽象類別」，而所有的 Pizza 次類別也依賴了 Pizza 抽象類別。

        最後提供幾個設計方針，能避免 OO 設計中，違反覆相依守則：

1. 變數不可持有具象類別的參考。可以改用工廠避開直接 new 的做法
2. 不要讓類別繼承自具象類別。繼承具象類別，就會依賴具象類別。請繼承自一個介面(或抽象類別)。
3. 不要讓次類別中的方法 override 超類別中的方法。如果要 override 超類別的方法，那超類別就不是一個適合被繼承的抽象。超類別中的方法，應該由所有次類別共享

        這些方針只是盡量去達到，不是隨時要遵守。例如有一個不會改變的類別，這時直接 new 也沒關係。而要是類別在未來可能改變時，可以使用一些技巧 (例如工廠) 將這些改變封裝起來。

參考資料:

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