抽象工廠設計模式（屬于“四人幫”的一部分）屬于“創新設計模式”類別，它提供了一種封裝一組具有公共鏈接的工廠的方法，而無需突出其具體類。 這就是工廠根據用戶需求在運行時創建各種對象的全部內容。 客戶仍然完全不知道（解耦）了從各個工廠獲得的具體產品，客戶只能訪問簡化的界面。

問題陳述：

我們將考慮與服裝工廠相同的先前示例，并對其進行擴展以理解抽象工廠的問題陳述。 考慮一家專門生產褲子和襯衫的服裝工廠。 現在，作為著名零售品牌的母公司正進入小工具領域。 他們還計劃擴大其工廠，在美國建立一個中心，在英國建立另一個中心。 客戶端應該完全不知道對象是如何創建的。 我們可以用來解決此要求的最佳設計模式是什么？

解：

為了解決上述設計問題，我們將使用抽象工廠模式。 如前所述，這是超級工廠。 使用工廠方法模式無法有效解決上述問題，因為這涉及與母公司或受撫養人相關的多個工廠和產品。
注意：在設計模式中，摘要和接口可以使用相同的名稱來引用。

結構體：

抽象工廠設計模式

在上圖中，創建的其他項是通過AbstractFactory的具有createProductA（）和createProductB（）方法的抽象附加層。 有多個ConcreteFactories可以實現AbstractFactory的方法。 客戶端現在僅訪問AbstractFactory接口。

另一部分是產品。 客戶端現在訪問不同的AbstractProduct接口AbstractProductA和AbstractProductB 。 所有用于AbstractProducts的ConcreteProducts都是由ConcreteFactories（ ConcreteFactory1和ConcreteFactory2 ）創建的，這是邏輯。

現在，讓我們看一下我們現實生活中的GarmentFactory示例，它與Factory Method模式有什么區別。

抽象工廠示例

在上面的現實示例中，RetailFactory是AbstractFactory類，該類現在在美國和英國等不同位置擁有多個Concrete工廠（UKFactory和USFactory），專門致力于分別創建襯衫/筆記本電腦和褲子/手機等多種產品。 在此示例中，我們還創建了另一個名為FactoryMaker的其他類，該類從客戶端中選擇Factory，然后將作業相應地委派給適當的Factory類。 客戶端完全不知道該處理的完成方式，并且僅引用RetailFactory接口以及GarmentType和GadgetType接口。 這種松散的耦合也有助于增加多個混凝土產品，而無需更改客戶代碼。

優點：

使用此模式，即使在運行時也可以在不更改客戶端代碼的情況下交換具體類。

退稅：

主要缺點之一是額外的復雜性和在初始階段編寫代碼。

有趣的一點：

• 抽象工廠，構建器和原型可以在其實現中使用Singleton。 抽象工廠模式通常與工廠方法一起使用，但是也可以使用原型模式來實現，以提高性能并簡化代碼。
• 抽象工廠可以用作Fa?ade模式的替代方案，以隱藏平臺特定的類
• AbstractFactory類僅聲明用于創建產品的接口。 實際的創建是ConcreteProduct類的任務，其中一個好的方法是為該系列的每個產品應用Factory Method設計模式。

抽象工廠和工廠方法模式之間的區別：

• Factory Method模式向客戶端公開了一種用于創建對象的方法，而在Abstract Factory的情況下，它們公開了可能由這些Factory方法組成的一系列相關對象。
• 設計始于使用工廠方法（復雜程度較低，更易于自定義的子類激增），并隨著設計人員發現需要更多靈活性的地方而向抽象工廠，原型或生成器（更靈活，更復雜）發展。
• 工廠方法模式隱藏單個對象的構造，而抽象工廠方法則隱藏一系列相關對象的構造。 抽象工廠通常使用一組工廠方法來實現。

參考： 抽象工廠設計模式在Idiotechie博客上由我們的JCG合作伙伴 Mainak Goswami 解釋 。

翻譯自: https://www.javacodegeeks.com/2012/10/abstract-factory-design-pattern-explained.html