介紹簡單工廠模式之前先通過一個披薩項目的例子來引出問題，然后給出簡單工廠模式這種解決方案，然后隨著披薩項目的不斷擴展，遇到新的問題，引出工廠方法模式，然后又遇到新的問題，引出最終解決方案，抽象工廠模式。
一、披薩項目介紹
比如一個披薩店 ，店長一名，目前賣兩種口味披薩，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、客戶端只知道傳入工廠類的參數，對于如何創建對象并不關心。
文章列表
留言列表
