上一次我們已經通過代碼，簡單的認識了工廠方法模式，具體的思路請移步到設計模式之工廠模式（二），進行查看。這次，讓我們通過設計模式的思想，來好好認識下工廠方法模式。

創(chuàng)建者和產品

所有工廠模式都用來封裝對象的創(chuàng)建。工廠方法模式（Factory Method Pattern）通過讓子類決定該創(chuàng)建的對象是什么，來達到將對象創(chuàng)建的過程封裝的目的。讓我們來看看這些類圖，以了解有哪些組成元素：

另一個觀點：平行的類層級

上面已經看到，將一個orderPizza()方法和一個工廠方法聯(lián)合起來，就可以成為一個框架。除此之外，工廠方法將生產知識封裝進各個創(chuàng)建者，這樣的做法，也可以被視為是一個框架。

讓我們來看看這兩個平行的類層級，并認清它們的關系：

定義工廠方法模式

工廠方法模式定義了一個創(chuàng)建對象的接口，但由子類決定要實例化的類是哪一個。工廠方法讓類把實例化推遲到子類。

工廠方法模式能夠封裝具體類型的實例化。看下面的類圖，抽象的Creator提供了一個創(chuàng)建對象的方法的接口，也稱為“工廠方法”。在抽象的Creator中，任何其他實現(xiàn)的方法，都可能使用到這個工廠方法所制造出來的產品，但只有子類真正實現(xiàn)這個工廠方法并創(chuàng)建產品。

對象依賴

假設你從未聽過工廠模式，那么按照之前的，如果要開一家紐約和芝加哥的披薩店，并且有各種風味的披薩對象，你是否可以想象這個類所以來的具體披薩對象有幾種呢？如果又增加了一種加州風味，又會有依賴多少個對象呢？不妨讓你看看：

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設計原則就正式闡明了這一點；這個原則甚至還有一個又響亮又正式的名稱：“依賴倒置原則”。要依賴抽象，不要依賴具體類。

這個原則和“針對接口編程，不針對實現(xiàn)編程”類似，但是這個原則，更強調“抽象”。這個原則說明了：不能讓高層組件依賴低層組件，而且，不管高層或低層組件，“兩者”都應該依賴于抽象。

所謂“高層”組件， 是是由其他低層組件定義行為的類。例如，PizzaStore是個高層組件，因為他的行為是由披薩定義的；PizzaStore創(chuàng)建所有不同的披薩對象，準備、烘烤、切片、裝盒；而披薩本身屬于低層組件。PizzaStore依賴這些具體披薩類。

原則的應用

非常依賴披薩店的主要問題在于：它依賴每個披薩類型。因為它是在自己的orderPizza()方法中，實例化這些具體類型的。

如何在orderPizza()方法中，將這些實例化對象的代碼獨立出來？我們都知道，工廠方法剛好派上用場了。應用了工廠方法之后，類圖就改成了下面這個樣子：

在應用工廠方法之后，你注意到了沒，高層組件（PizzaStore）和低層組件（也就是這些披薩）都依賴了Pizza抽象。想要遵循依賴倒置原則，工廠方法并非是唯一的技巧，但卻是最有威力的技巧之一了。

依賴倒置，究竟倒置在哪里？

在依賴倒置原則中的倒置指的是和一般OO設計的思考方式相反。看看上面的圖，你會注意到低層組件現(xiàn)在竟然依賴高層的抽象。同樣地，高層組件現(xiàn)在也依賴相同的抽象。以前繪制的依賴圖都是自上而下的，現(xiàn)在卻倒置了，而且高層和低層模塊現(xiàn)在都依賴這個抽象。

依賴倒置，還需要倒置你的思考方式。之前如果你需要設計一個披薩店，會從頂端開始，然后往下到具體類。現(xiàn)在就需要倒置你的想法，別從頂端開始，而是從披薩開始，然后想到抽象化一個Pizza類。繼而想到必須要靠一個工廠來將這些類取出披薩店，不同的披薩類型都只能依賴一個抽象，同樣的披薩店也會依賴這個抽象。

就這樣，我們倒置了一個商店依賴具體類的設計，而且也倒置了你的思考方式。但是，也需要避免在OO設計中違反依賴倒置原則：

變量不可以持有具體類的引用：如果使用new，就會持有具體類的引用。你可以改用工廠來避開這樣的做法

不要讓類派生自具體類：如果派生自具體類，你就會依賴具體類。請派生自一個抽象（接口或抽象類）

不要覆蓋基類中已實現(xiàn)的方法：如果覆蓋基類已實現(xiàn)的方法，那么你的基類就不是一個真正適合被繼承的抽象。基類中已實現(xiàn)的方法，應該由所有的子類共享

所以，這篇我們就在這里結束了。為什么呢，因為在下一篇，我們需要遵循這個設計原則，重新來整理整理我們的披薩店。我們要讓披薩店的設計變得更棒：具有彈性的框架，而且遵循設計原則。這篇偏向理論知識了，請各位好好理解理解，看看創(chuàng)建者和產品類，看看依賴倒置原則，我們下篇再見咯。

愛生活，愛學習，愛感悟，愛挨踢

轉載于:https://juejin.im/post/5cbd42956fb9a032060c2615

總結

以上是生活随笔為你收集整理的设计模式之工厂模式（三）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。