設計模式之工廠模式（一）

Dimple91發表於2019-04-16

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

除了使用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)。但是不要因為簡單工廠不是一個設計模式，就忽略了他。讓我們來看看新的披薩店的類圖：