抽象工厂设计模式(属于“四人帮”的一部分)属于“创新设计模式”类别,它提供了一种封装一组具有公共链接的工厂的方法,而无需突出其具体类。 这就是工厂根据用户需求在运行时创建各种对象的全部内容。 客户仍然完全不知道(解耦)了从各个工厂获得的具体产品,客户只能访问简化的界面。
定义: |
抽象工厂设计模式提供了一个接口,用于创建相关或相关对象的族,而无需指定其具体类。 |
问题陈述:
我们将考虑与服装工厂相同的先前示例,并对其进行扩展以理解抽象工厂的问题陈述。 考虑一家专门生产裤子和衬衫的服装工厂。 现在,作为著名零售品牌的母公司正进入小工具领域。 他们还计划扩大其工厂,在美国建立一个中心,在英国建立另一个中心。 客户端应该完全不知道对象是如何创建的。 我们可以用来解决此要求的最佳设计模式是什么?
解:
为了解决上述设计问题,我们将使用抽象工厂模式。 如前所述,这是超级工厂。 使用工厂方法模式无法有效解决上述问题,因为这涉及与母公司或受抚养人相关的多个工厂和产品。
注意:在设计模式中,摘要和接口可以使用相同的名称来引用。
结构体:
在上图中,创建的其他项是通过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接口。 这种松散的耦合也有助于增加多个混凝土产品,而无需更改客户代码。
优点:
使用此模式,即使在运行时也可以在不更改客户端代码的情况下交换具体类。
退税:
主要缺点之一是额外的复杂性和在初始阶段编写代码。
你知道吗? |
---|
JEE中的数据访问对象使用(GoF)抽象工厂模式从RdbDAOFactory,XmlDAOFactory,OdbDAOFactory创建各种产品DAO。 |
有趣的一点:
- 抽象工厂,构建器和原型可以在其实现中使用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