設計模式：簡單工廠模式

介紹簡單工廠模式之前先通過一個披薩項目的例子來引出問題，然後給出簡單工廠模式這種解決方案，然後随着披薩項目的不斷擴充，遇到新的問題，引出工廠方法模式，然後又遇到新的問題，引出最終解決方案，抽象工廠模式。

一、披薩項目介紹

比如一個披薩店，店長一名，目前賣兩種口味披薩，GreekPizza和CheesePizza，每個披薩都有prePare()，bake()，cut()，box()這4種步驟，原料，烘培，切割，打包，最後給使用者吃。

把上述這個過程抽象後，設計如下：

Pizza披薩抽象類:

package com.factoryPattern.simpleFactory;

public abstract class Pizza {
    
    public abstract void prepare();
    public abstract void bake();
    public abstract void cut();
    public abstract void box();
}

GreekPizza披薩類:

package com.factoryPattern.simpleFactory;

public class GreekPizza extends Pizza{
    
    public void prepare(){
       System.out.println("準備GreekPizza~");
    }
    public void bake(){
        System.out.println("正在烤GreekPizza~");
    }
    public void cut(){
        System.out.println("正在切GreekPizza~");
    }
    public void box(){
        System.out.println("正在打包GreekPizza~");
    }

}

CheesePizza披薩類:

package com.factoryPattern.simpleFactory;

public class CheesePizza extends Pizza{
    
    public void prepare(){
       System.out.println("準備CheesePizza~");
    }
    public void bake(){
        System.out.println("正在烤CheesePizza~");
    }
    public void cut(){
        System.out.println("正在切CheesePizza~");
    }
    public void box(){
        System.out.println("正在打包CheesePizza~");
    }
}

用戶端，店長根據客戶點的餐生成不同的披薩：

try{
    Pizza pizza;
    if("cheese".equal(orderType)) pizza = new CheesePizza();
    if("greek".equal(orderType)) pizza = new GreekPizza();
}catch(Exception e){
...
}

業務很簡答，根據使用者想買的披薩，生成不同的披薩。傳統的設定這樣也沒錯，如果業務發展，會造成什麼問題呢？

現在如果多了一種口味

qiaokeliPizza

，正常辦法是生成一個

QiaokeliPizza

類，繼承于

Pizza

，然後在

OrderPizza

中，添加

if("qiaokeli".equal(orderType)) pizza = new QiaokeliPizza();

如果後來披薩口味越來越多，負責點餐的店長會很不開心的，既要點餐又要做披薩，一個人忙不夠來，希望請一個廚師來專門做披薩，那樣他才會輕松點。

他所想的解決方案，簡單工廠模式就可以做到。

二、簡單工廠模式

簡單工廠模式是類的建立模式，又叫做靜态工廠方法（

Static Factory Method

）模式。簡單工廠模式是由一個工廠對象決定建立出哪一種産品類的執行個體。

簡單工廠模式的結構如下：

從圖中可以看出，簡單工廠模式涉及到工廠角色，抽象産品角色以及具體産品角色等三個角色：

工廠類（ Factory ）角色：擔任這個角色的是工廠方法模式的核心，含有與應用緊密相關的商業邏輯。
抽象産品（ Product ）角色：擔任這個角色的類是由工廠方法模式所建立的對象的父類，或它們共同擁有的接口，這裡指的就是 Pizza 這個類。
具體産品（ Concrete Product ）角色：工廠方法模式所建立的任務對象都是這個角色的執行個體，這裡指 GreekPizza 和 CheesePizza 。

把上面的披薩項目用簡單工廠模式來現實的話，無非就是建立一個工廠類（廚師）來接管店長之前要做得烤披薩的活，而店長隻要告訴這個工廠類（廚師）他需要哪種披薩就好。

代碼示例講解：

SimplePizzaFactory簡單工廠類，根據傳遞的參數來準備不同的披薩：

public class SimplePizzaFactory {
    public static Pizza CreatePizza(String orderType){
        Pizza pizza = null;
        if (orderType.equals("cheese")) {
            pizza = new CheesePizza();
        } else if (orderType.equals("greek")) {
            pizza = new GreekPizza();
        }
        return pizza;
    }
}

在使用時，店長隻需要調用工廠類SimplePizzaFactory的靜态方法CreatePizza()即可：

try{
Pizza pizza;
pizza=SimplePizzaFactory.CreatePizza("cheese");
pizza=SimplePizzaFactory.CreatePizza("greek");
}catch(Exception e){
...
}

這樣設計後，店長就輕松多了，隻要負責告訴工廠類（廚師）需要什麼類型的披薩就可以，終于不要擔心搞錯了而負責任。

三、總結

上面用披薩項目的列子來講解了簡單工廠模式的使用，總結下優缺點：

簡單工廠模式的優點：

模式的核心是工廠類。這個類含有必要的判斷邏輯，可以決定在什麼時候建立哪一個産品類的執行個體。而用戶端則可以免除直接建立對象的責任（比如那個服務員）。簡單工廠模式通過這種做法實作了對責任的分割。

簡單工廠模式的缺點：

這個工廠類集中了所有的建立邏輯，當有複雜的多層次等級結構時，所有的業務邏輯都在這個工廠類中實作。什麼時候它不能工作了，整個系統都會受到影響。并且簡單工廠模式違背了開閉原則（對擴充的開放，對修改的關閉）。

适用場景：

在以下情況下可以考慮使用簡單工廠模式：

1、工廠類負責建立的對象比較少，由于建立的對象較少，不會造成工廠方法中的業務邏輯太過複雜。

2、用戶端隻知道傳入工廠類的參數，對于如何建立對象并不關心。