前面說過其中之一的設計原則我們不應該依賴實現程式設計，但是當我們每次用new時不正是在依賴實現程式設計嗎

Duck duck = new MallardDuck(); 

正如上面的程式碼，我們使用介面讓程式碼有了彈性，但是還是得建立具體類的例項，當有一群相關的具體類時通常會寫出這樣的程式碼：

Duck duck; if(picnic){ duck = new MallardDuck(); } else if(hunting) { duck = new DecoyDuck(); } else if(inBathTub) { duck = new RubberDuck(); } 

當看到這樣的程式碼，一旦有變化或擴充套件，就要重新開啟這段程式碼進行修改，這違背了對修改關閉的原則，通常這樣修改過的程式碼將造成部分系統更難維護和更新，而且更容易犯錯。那怎麼辦呢，想想前面所有的設計原則之一：封裝變化。那麼我們開始識別變化的部分吧。

    假設你有個比薩店，身為比薩店得主人，你的程式碼可能這樣寫：

Pizza orderPizza() { //為了讓系統更有彈性，我們很希望這是個抽象類或介面 //但如果這樣，這些類或介面就無法例項化 Pizza pizza = new Pizza(); pizza.prepare(); pizza.bake(); pizza.cut(); pizza.box(); return pizza; } 

如果你需要更多的比薩，必須增加一些程式碼，來根據比薩的型別來製造比薩：

Pizza orderPizza(String type){ Pizza pizza; if(type.equals("cheese")) { pizza = new CheesePizza(); } else if(type.equals("greek")) { pizza = new GreekPizza(); } else if(type.equals("pepperoni")) { pizza = new PepperoniPizza(); } pizza.prepare(); pizza.bake(); pizza.cut(); pizza.box(); return pizza; }

但壓力來自於增加更多的比薩，或者某種比薩賣的不好我想從比薩店去掉，就要一再修改剛增加上的程式碼，但是比薩的準備，烘烤，包裝多年來很少變，變的只是被製作的物件而已。既然已經看出來那些變化，那些不變化的地方，是我們封裝變化的時候了，將建立物件移到orderPizzas()之外，移到別的地方，這個地方我們稱之為工廠，但需要比薩時就向工廠要，至於比薩產生的細節我不關心，我只關心我是否能拿到比薩。我們建立一個簡單比薩工廠：

public class SimplePizzaFactory { public Pizza orderPizza(String type){ Pizza pizza = null; if(type.equals("cheese")) { pizza = new CheesePizza(); } else if(type.equals("pepperoni")) { pizza = new PepperoniPizza(); } else if(type.equals("clam")) { pizza = new ClamPizza(); } else if(type.equals("veggie")) { pizza = new VeggiePizza(); } return pizza; } }

是時候修改我們的客戶程式碼了，我們所要做的是向工廠要比薩，其他不用關心：

public class PizzaStore { SimplePizzaFactory factory; public PizzaStore(SimplePizzaFactory factory) { this.factory = factory; } public Pizza orderPizza(String type){ Pizza pizza; //這裡我們把new替換成了工廠建立方法 pizza = factory.createPizza(type); pizza.prepare(); pizza.bake(); pizza.cut(); pizza.box(); return pizza; } }  

上面的簡單工廠其實不是一個設計模式，反而更像一種程式設計習慣。有些程式設計人員習慣把它誤認為是“工廠模式”。但也不要因為簡單工廠不是一個真正的模式，就忽略他的用法，讓我們看看新的比薩店的類圖：

謝謝簡單工廠為我們暖身。接下來登場的是兩個重量級模式，他們都是工廠，你將會看到更多的比薩。