上一次我們已經通過程式碼，簡單的認識了工廠方法模式，具體的思路請移步到設計模式之工廠模式（二），進行檢視。這次，讓我們通過設計模式的思想，來好好認識下工廠方法模式。
建立者和產品
所有工廠模式都用來封裝物件的建立。工廠方法模式（Factory Method Pattern）通過讓子類決定該建立的物件是什麼，來達到將物件建立的過程封裝的目的。讓我們來看看這些類圖，以瞭解有哪些組成元素：
另一個觀點：平行的類層級
上面已經看到，將一個orderPizza()方法和一個工廠方法聯合起來，就可以成為一個框架。除此之外，工廠方法將生產知識封裝進各個建立者，這樣的做法，也可以被視為是一個框架。
讓我們來看看這兩個平行的類層級，並認清它們的關係：
定義工廠方法模式
工廠方法模式定義了一個建立物件的介面，但由子類決定要例項化的類是哪一個。工廠方法讓類把例項化推遲到子類。
工廠方法模式能夠封裝具體型別的例項化。看下面的類圖，抽象的Creator提供了一個建立物件的方法的介面，也稱為“工廠方法”。在抽象的Creator中，任何其他實現的方法，都可能使用到這個工廠方法所製造出來的產品，但只有子類真正實現這個工廠方法並建立產品。
物件依賴
假設你從未聽過工廠模式，那麼按照之前的，如果要開一家紐約和芝加哥的披薩店，並且有各種風味的披薩物件，你是否可以想象這個類所以來的具體披薩物件有幾種呢？如果又增加了一種加州風味，又會有依賴多少個物件呢？不妨讓你看看：
public lass DependentPizzaStore {
public Pizza createPizza(String style, String type) {
Pizza pizza = null;
if(style.equals("NY")) {
if(type.equals("cheese")) {
pizza = new NYStyleCheesePizza();
} else if(tpye.equals("clam")) {
pizza = new NYStyleClamPizza();
} else if(type.equals("pepperoni")) {
pizza = new NYStylePrpperoniPizza();
}
} else if(style.equals("Chicago")) {
if(type.equals("cheese")) {
pizza = new ChicagoStyleCheesePizza();
} else if(tpye.equals("clam")) {
pizza = new ChicagoStyleClamPizza();
} else if(type.equals("pepperoni")) {
pizza = new ChicagoStylePrpperoniPizza();
}
} else {
System.out.println("Error: invalid type of pizza");
return null;
}
}
}
複製程式碼當你直接例項化一個物件時，就是在依賴它的具體類。如果把這個版本的披薩店和它的依賴物件畫成一張畫，看起來是這樣的：
依賴倒置原則
從上面看到了，我們程式碼裡減少對於具體類的依賴是一件好事。事實上，有一個OO設計原則就正式闡明瞭這一點；這個原則甚至還有一個又響亮又正式的名稱：“依賴倒置原則”。要依賴抽象，不要依賴具體類。
這個原則和“針對介面程式設計，不針對實現程式設計”類似，但是這個原則，更強調“抽象”。這個原則說明了：不能讓高層元件依賴低層元件，而且，不管高層或低層元件，“兩者”都應該依賴於抽象。
所謂“高層”元件， 是是由其他低層元件定義行為的類。例如，PizzaStore是個高層元件，因為他的行為是由披薩定義的；PizzaStore建立所有不同的披薩物件，準備、烘烤、切片、裝盒；而披薩本身屬於低層元件。PizzaStore依賴這些具體披薩類。
原則的應用
非常依賴披薩店的主要問題在於：它依賴每個披薩型別。因為它是在自己的orderPizza()方法中，例項化這些具體型別的。
如何在orderPizza()方法中，將這些例項化物件的程式碼獨立出來？我們都知道，工廠方法剛好派上用場了。應用了工廠方法之後，類圖就改成了下面這個樣子：
在應用工廠方法之後，你注意到了沒，高層元件（PizzaStore）和低層元件（也就是這些披薩）都依賴了Pizza抽象。想要遵循依賴倒置原則，工廠方法並非是唯一的技巧，但卻是最有威力的技巧之一了。
依賴倒置，究竟倒置在哪裡？
在依賴倒置原則中的倒置指的是和一般OO設計的思考方式相反。看看上面的圖，你會注意到低層元件現在竟然依賴高層的抽象。同樣地，高層元件現在也依賴相同的抽象。以前繪製的依賴圖都是自上而下的，現在卻倒置了，而且高層和低層模組現在都依賴這個抽象。
依賴倒置，還需要倒置你的思考方式。之前如果你需要設計一個披薩店，會從頂端開始，然後往下到具體類。現在就需要倒置你的想法，別從頂端開始，而是從披薩開始，然後想到抽象化一個Pizza類。繼而想到必須要靠一個工廠來將這些類取出披薩店，不同的披薩型別都只能依賴一個抽象，同樣的披薩店也會依賴這個抽象。
就這樣，我們倒置了一個商店依賴具體類的設計，而且也倒置了你的思考方式。但是，也需要避免在OO設計中違反依賴倒置原則：
- 變數不可以持有具體類的引用：如果使用new，就會持有具體類的引用。你可以改用工廠來避開這樣的做法
- 不要讓類派生自具體類：如果派生自具體類，你就會依賴具體類。請派生自一個抽象（介面或抽象類）
- 不要覆蓋基類中已實現的方法：如果覆蓋基類已實現的方法，那麼你的基類就不是一個真正適合被繼承的抽象。基類中已實現的方法，應該由所有的子類共享
所以，這篇我們就在這裡結束了。為什麼呢，因為在下一篇，我們需要遵循這個設計原則，重新來整理整理我們的披薩店。我們要讓披薩店的設計變得更棒：具有彈性的框架，而且遵循設計原則。這篇偏向理論知識了，請各位好好理解理解，看看建立者和產品類，看看依賴倒置原則，我們下篇再見咯。