工廠模式的學習篇幅比較長，小編第一次看書的時候，就一口氣花了一個多小時，還是通讀。後面又斷斷續續地繼續瞭解了下，力爭做到清晰的認知，給大家一個簡單的學習方式。所以，這次模組分的可能會比之前的多，涉及到多個工廠模式。好的，我們繼續衝鴨！！！
除了使用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