抽象工厂设计模式（属于“四人帮”的一部分）属于“创新设计模式”类别，它提供了一种封装一组具有公共链接的工厂的方法，而无需突出其具体类。 这就是工厂根据用户需求在运行时创建各种对象的全部内容。 客户仍然完全不知道（解耦）了从各个工厂获得的具体产品，客户只能访问简化的界面。

问题陈述：

我们将考虑与服装工厂相同的先前示例，并对其进行扩展以理解抽象工厂的问题陈述。 考虑一家专门生产裤子和衬衫的服装工厂。 现在，作为著名零售品牌的母公司正进入小工具领域。 他们还计划扩大其工厂，在美国建立一个中心，在英国建立另一个中心。 客户端应该完全不知道对象是如何创建的。 我们可以用来解决此要求的最佳设计模式是什么？

解：

为了解决上述设计问题，我们将使用抽象工厂模式。 如前所述，这是超级工厂。 使用工厂方法模式无法有效解决上述问题，因为这涉及与母公司或受抚养人相关的多个工厂和产品。
注意：在设计模式中，摘要和接口可以使用相同的名称来引用。

结构体：

抽象工厂设计模式

在上图中，创建的其他项是通过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