跳到主要內容

工廠模式 - 工廠方法模式 (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. 

  2. 不要讓類別繼承自具象類別。繼承具象類別，就會依賴具象類別。請繼承自一個介面(或抽象類別)。
    3. 

  3. 不要讓次類別中的方法 override 超類別中的方法。如果要 override 超類別的方法，那超類別就不是一個適合被繼承的抽象。超類別中的方法，應該由所有次類別共享
    4. 






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



參考資料:



        深入淺出設計模式(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...




















1 則留言









閱讀完整內容






























裝飾者模式 (Decorator Pattern)




























        假如你有一間飲料店, 目前只有賣幾種咖啡。因為生意很好, 因此想更換菜單…          以下是目前菜單的類別圖:             簡單說明此類別圖, cost() 是抽象的, 子類別要實作自己的 cost() 來告知飲料的價格。           買咖啡時, 也可要求要加料, 例如牛奶(Milk)、摩卡(Mocha，就是巧克力口味)。這樣的新類別要如何設計呢 ? 看起來是不能直接新增所需的子類別, 例如 EspressoWithMilk, EspressoWithMilkAndMocha, DarkRoastWithMilk, DarkRoastWithMilkAndMocha… 這樣加下去, 日後飲料跟配料越來越多時, 類別也就越多, 這實在不是個好設計。           換個方式設計呢, 在 Beverage 裡面加入所有的配料如何 ? 這樣好像也不太好, 未來要是配料有更動, Beverage 程式碼就要重寫, 而未來要是有新口味的飲料時, 有些配料就不太合理 ( 薑茶加摩卡 ? ), 更麻煩的是, 無法應付機車的客人 (例如要加 3 份牛奶)。這時候裝飾者模式就能上場啦。在介紹裝飾者模式前, 先說明其設計守則:    類別應該開放, 以便擴充 ; 應該關閉, 禁止修改。             我們的目標是允許類別容易擴充, 在不修改現有程式碼的情形就能搭配新的行為。這樣的設計具有彈性, 可以接受新功能以達到改變需求的目的。這看起來好像有點矛盾, 但是的確有一些技術可以在不直接修改程式碼的情形下進行擴充, 如裝飾者模式。             這時候應該有人會問: 那是不是以後我的專案架構設計都遵循這個守則就是好設計了 ? 答案是不太可能, 也沒這必要, 就算做得到, 也可能是浪費, 容易導致程式碼複雜且難以理解。只需小心選擇哪些部分未來會擴充, 這些部份遵循這個設計守則即可。             接下來...




















張貼留言









閱讀完整內容






























狀態模式 (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");         }        ...




















3 則留言









閱讀完整內容