工廠方法模式VS抽象工廠模式

抽象工廠模式

抽象工廠模式（Abstract Factory Pattern）是圍繞一個超級工廠建立其他工廠。該超級工廠又稱為其他工廠的工廠。這種類型的設計模式屬于建立型模式，它提供了一種建立對象的最佳方式。

在抽象工廠模式中，接口是負責建立一個相關對象的工廠，不需要顯式指定它們的類。每個生成的工廠都能按照工廠模式提供對象。

介紹

意圖：提供一個建立一系列相關或互相依賴對象的接口，而無需指定它們具體的類。

主要解決：主要解決接口選擇的問題。

何時使用：系統的産品有多于一個的産品族，而系統隻消費其中某一族的産品。

如何解決：在一個産品族裡面，定義多個産品。

關鍵代碼：在一個工廠裡聚合多個同類産品。

應用執行個體：工作了，為了參加一些聚會，肯定有兩套或多套衣服吧，比如說有商務裝（成套，一系列具體産品）、時尚裝（成套，一系列具體産品），甚至對于一個家庭來說，可能有商務女裝、商務男裝、時尚女裝、時尚男裝，這些也都是成套的，即一系列具體産品。假設一種情況（現實中是不存在的，要不然，沒法進入共産主義了，但有利于說明抽象工廠模式），在您的家中，某一個衣櫃（具體工廠）隻能存放某一種這樣的衣服（成套，一系列具體産品），每次拿這種成套的衣服時也自然要從這個衣櫃中取出了。用 OO 的思想去了解，所有的衣櫃（具體工廠）都是衣櫃類的（抽象工廠）某一個，而每一件成套的衣服又包括具體的上衣（某一具體産品），褲子（某一具體産品），這些具體的上衣其實也都是上衣（抽象産品），具體的褲子也都是褲子（另一個抽象産品）。

優點：當一個産品族中的多個對象被設計成一起工作時，它能保證用戶端始終隻使用同一個産品族中的對象。

缺點：産品族擴充非常困難，要增加一個系列的某一産品，既要在抽象的 Creator 裡加代碼，又要在具體的裡面加代碼。

使用場景： 1、QQ 換皮膚，一整套一起換。 2、生成不同作業系統的程式。

注意事項：産品族難擴充，産品等級易擴充。

工廠方法模式

工廠模式（Factory Pattern）是 Java 中最常用的設計模式之一。這種類型的設計模式屬于建立型模式，它提供了一種建立對象的最佳方式。

在工廠模式中，我們在建立對象時不會對用戶端暴露建立邏輯，并且是通過使用一個共同的接口來指向新建立的對象。

介紹

意圖：定義一個建立對象的接口，讓其子類自己決定執行個體化哪一個工廠類，工廠模式使其建立過程延遲到子類進行。

主要解決：主要解決接口選擇的問題。

何時使用：我們明确地計劃不同條件下建立不同執行個體時。

如何解決：讓其子類實作工廠接口，傳回的也是一個抽象的産品。

關鍵代碼：建立過程在其子類執行。

應用執行個體： 1、您需要一輛汽車，可以直接從工廠裡面提貨，而不用去管這輛汽車是怎麼做出來的，以及這個汽車裡面的具體實作。 2、Hibernate 換資料庫隻需換方言和驅動就可以。

優點： 1、一個調用者想建立一個對象，隻要知道其名稱就可以了。 2、擴充性高，如果想增加一個産品，隻要擴充一個工廠類就可以。 3、屏蔽産品的具體實作，調用者隻關心産品的接口。

缺點：每次增加一個産品時，都需要增加一個具體類和對象實作工廠，使得系統中類的個數成倍增加，在一定程度上增加了系統的複雜度，同時也增加了系統具體類的依賴。這并不是什麼好事。

使用場景： 1、日志記錄器：記錄可能記錄到本地硬碟、系統事件、遠端伺服器等，使用者可以選擇記錄日志到什麼地方。 2、資料庫通路，當使用者不知道最後系統采用哪一類資料庫，以及資料庫可能有變化時。 3、設計一個連接配接伺服器的架構，需要三個協定，”POP3”、”IMAP”、”HTTP”，可以把這三個作為産品類，共同實作一個接口。

注意事項：作為一種建立類模式，在任何需要生成複雜對象的地方，都可以使用工廠方法模式。有一點需要注意的地方就是複雜對象适合使用工廠模式，而簡單對象，特别是隻需要通過 new 就可以完成建立的對象，無需使用工廠模式。如果使用工廠模式，就需要引入一個工廠類，會增加系統的複雜度。

參考自：http://www.runoob.com/design-pattern/design-pattern-tutorial.html