抽象工厂模式设计模式

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

问题陈述：

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

解：

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

结构体：

抽象工厂设计模式

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

抽象工厂模式设计模式