上一次我們已經通過代碼，簡單的認識了工廠方法模式，具體的思路請移步到設計模式之工廠模式（二），進行查看。這次，讓我們通過設計模式的思想，來好好認識下工廠方法模式。
創建者和產品
所有工廠模式都用來封裝對象的創建。工廠方法模式（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，就會持有具體類的引用。你可以改用工廠來避開這樣的做法
- 不要讓類派生自具體類：如果派生自具體類，你就會依賴具體類。請派生自一個抽象（接口或抽象類）
- 不要覆蓋基類中已實現的方法：如果覆蓋基類已實現的方法，那么你的基類就不是一個真正適合被繼承的抽象。基類中已實現的方法，應該由所有的子類共享
所以，這篇我們就在這里結束了。為什么呢，因為在下一篇，我們需要遵循這個設計原則，重新來整理整理我們的披薩店。我們要讓披薩店的設計變得更棒：具有彈性的框架，而且遵循設計原則。這篇偏向理論知識了，請各位好好理解理解，看看創建者和產品類，看看依賴倒置原則，我們下篇再見咯。
