工廠模式的學習篇幅比較長，小編第一次看書的時候，就一口氣花了一個多小時，還是通讀。后面又斷斷續續地繼續了解了下，力爭做到清晰的認知，給大家一個簡單的學習方式。所以，這次模塊分的可能會比之前的多，涉及到多個工廠模式。好的，我們繼續沖鴨！！！
除了使用new操作符之外，還有更多制造對象的方法。我們將了解到實例化這個活動不應該總是公開地進行，也會認識到初始化經常會造成“耦合”問題。所以，這肯定不是我們希望的這樣對吧？繼續學習下去，我們將了解工廠模式如何從復雜的依賴中幫你脫困。
當看到“new”，就會想到“具體”
很多朋友應該有一個疑惑，之前說的原則，不應該針對實現編程，但是當我們每次使用new的時候，其實就是在針對實現編程呀。使用了“new”，就是在實例化一個具體類，所以用的的確是實現，而不是接口。遇到一個類的情況，還好說，但是遇到多個類，就必須等到運行時，才知道該實例化哪一個。
Duck duck;
if(picnic) {
duck = new MallardDuck();
} else if (hunting) {
duck = new DecoyDuck();
} else if (inBathTub) {
duck = new RubberDuck();
}
這段代碼如果一旦有變化擴展，就必須重新打開這段代碼進行檢查和修改，勢必會造成部分系統更難維護和更新，也更容易犯錯。
“new”有什么不對勁
針對Java程序來說，new是最最基礎的部分了，所以從技術上來說，new絲毫沒有問題，問題的關鍵在於經常要進行的改變。
針對接口編程，可以隔離掉以后系統可能發生的一大堆改變。為啥呢？如果代碼是針對接口編程，那么通過多態可以與任何新類實現該接口。但是，當代碼使用大量的具體類時，這就很麻煩了，就必須對代碼進行改變。也就是說，你的代碼並非“對修改關閉”。想用新的具體類型來擴展代碼，就必須重新 打開它。
所以，有沒有解決辦法呢？還記得我們的第一個原則不，就是用來改變，並幫我們“找出會變化的方面，把它們從不變的部分分離出來”。
之前的裝飾者模式，我們喝了可口的咖啡，那么在工廠模式里，就讓我們給咖啡加點搭配，來嘗嘗披薩的口味吧。
識別變化的方面，以及你的初步判斷
假設你有一個披薩店，為了讓系統有彈性，很是希望這是一個抽象類或接口。但如果這樣，這些類或接口就無法直接實例化了。
Pizza orderPizza() {
Pizza pizza = new Pizza();
pizza.prepare();
pizza.bake();
pizza.cut();
pizza.box();
return pizza
}
所以，我們還是需要增加一些代碼，來“決定”適合披薩的類型，然后再“制造”披薩：
public Pizza orderPizza(String type) {
Pizza pizza;
// 根據披薩的類型，我們實例化正確的具體類，然后將其賦值給pizza實例化變量。
// 請注意，這里的任何披薩都必須實現Pizza接口
if ("cheese".equals(type)) {
pizza = new CheesePizza();
} else if ("greek".equals(type)) {
pizza = new GreekPizza();
} else if ("pepperoni".equals(type)) {
pizza = new PepperoniPizza();
}
// 一旦我們有了披薩，需要做一些必要的工作。每個Pizza的子類型都知道如何准備自己
pizza.prepare();
pizza.bake();
pizza.cut();
pizza.box();
return pizza;
}
但是壓力來自增加更多的披薩類型
但是，每個產業都會存在競爭對手的，是吧。當其他的披薩店開發出了新產品，你怎么辦呢。比如人家有了Clam Pizza、Veggie Pizza。還能怎么辦，必須與時俱進，與對手一同進步，把這些披薩加入到你的店里，順帶淘汰一些過時了的披薩。
完蛋了，如果要增加披薩，又要去淘汰過時的披薩，在程序的世界里就是實例化某些類，刪除某些實例化的類。orderPizza()出問題了，我們無法讓orderPizza()對修改關閉；所以，我們用到了第一節學到的封裝，我們要封裝這些增刪改的東西。
封裝創建對象的代碼
那么封裝什么才是符合我們預期的呢，顯而易見，現在最好將創建對象移到orderPizza()之外。但怎么做呢？我們要把創建披薩的代碼移到另一個對象中，由這個對象專職創建披薩。
if ("cheese".equals(type)) {
pizza = new CheesePizza();
} else if ("greek".equals(type)) {
pizza = new GreekPizza();
} else if ("pepperoni".equals(type)) {
pizza = new PepperoniPizza();
}
就是把這個移走，新建一個對象，這個新對象只管如何創建披薩。如果任何對象想要創建披薩，直接就找這個即可。
我們稱這個新對象為“工廠”，並建造工廠
工廠（factory）處理創建對象的細節，一旦有了SimplePizzaFactory，orderPizza()就變成此對象的客戶。現在，我們方式很簡單了，當你想要一個披薩的時候，你就叫披薩工廠去做一個就好了。orderPizza()方法只關心從工廠得到了一個披薩，而這個披薩實現了Pizza接口，所以他可以調用prepare()、bake()、cut()、box()來分別進行准備、烘烤、切片、盒裝。
那我們把這個工廠建造起來吧，還不趕緊的。
// 這個工廠只做一件事，幫他的客戶創建披薩
public class SimplePizzaFactory {
// 在工廠內定義一個方法createPizza()方法，所有客戶用這個方法來實例化新對象
public Pizza createPizza(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;
}
}
雖然這個類還是需要進行頻繁的增刪改的，還是有點麻煩，但是相比之前呢。為什么這么說，因為這個類，還可以有很多行為，這會兒是創建披薩，那也許是創建菜單呢，又或者是創建餓了么外賣呢，都可以在這個工廠類里創建出來，其他類，只需要調用即可。所以，也就是說，當以后有任何改變，只需要修改這個類即可，省去你在其他地方操作的煩惱。
有了工廠類，其他類的操作就要隨之更改了。PizzaStore類需要把這個工廠加進來，畢竟我們什么事情都交給工廠去完成了。修改如下：
// 你需要更多的披薩類型傳入orderPizza()
public Pizza orderPizza(String type) {
Pizza pizza;
pizza = factory.createPizza(type);
// 一旦我們有了披薩，需要做一些必要的工作。每個Pizza的子類型都知道如何准備自己
pizza.prepare();
pizza.bake();
pizza.cut();
pizza.box();
return pizza;
}
定義簡單工廠
簡單工廠其實不是一個設計模式，反而比較像是一種變成習慣。但由於經常被使用，所以在書中，給他一個“Head First Pattern榮譽獎”。有些開發人員的確是把這個編程習慣誤認為是“工廠模式”(Factory Pattern)。但是不要因為簡單工廠不是一個設計模式，就忽略了他。讓我們來看看新的披薩店的類圖：
好啦，工廠模式的熱身結束啦。謝謝簡單工廠模式給我們暖身，之后我們會進入兩個重量級的模式，他們都是工廠。所以，別擔心你吃不到披薩，后面還會有更多的披薩呢。
再提醒一次，在設計模式中，所謂的“實現一個接口”並“不一定”表示“寫一個類，並利用implement關鍵詞來實現某個Java接口”。“實現一個接口”泛指“實現某個超類型（可以使類或接口）的某個方法”。
簡單工廠你get了嗎？
推薦閱讀：
GitHub地址 HeadFirstDesign
