为什么我们需要抽象工厂设计模式？

Question

大多数定义说:

抽象工厂提供了一个接口,用于创建相关对象的族,而无需指定其具体类

抽象工厂模式的用途是什么,因为我们可以通过创建具体类本身的对象来实现任务.为什么我们有一个工厂方法来创建Concrete类的对象？

请提供我必须实现abstractFactory模式的任何现实生活示例？

Answer 1

抽象工厂是依赖注入(DI)的一个非常核心的设计模式.这是Stack Overflow问题列表,其中Abstract Factory的应用程序已被接受为解决方案.

据我所知,这些问题代表了人们所面临的真实问题或问题,所以这应该让你从一些真实的例子开始:

• 是否有用于初始化通过DI容器创建的对象的模式
• 不能组合工厂/ DI
• WCF依赖注入和抽象工厂
• 当密钥类需要Session(或其他特定于上下文的变量)时如何设置IoC
• 如何根据最终用户配置值解析类型？
• 使用Unity的策略模式和依赖注入
• 在IoC顶部的抽象工厂模式？
• 这是使用和测试使用工厂模式的类的正确方法吗？
• DDD Book,Eric Evans:请解释"FACTORY应该被抽象为所需的类型而不是创建的具体类".
• DI容器,工厂或新的短暂物体？
• 如何单元测试实例创建？
• 用户输入依赖注入的最佳策略是什么？

Answer 2

使用抽象工厂模式的现实例子是提供对两个不同数据源(例如SQL数据库和XML文件)的数据访问.您有两个不同的数据访问类(数据存储的网关).两者都继承自定义要实现的常用方法的基类(例如,加载,保存,删除).

应使用哪个数据源不应改变客户端代码检索数据访问类的方式.您的抽象工厂知道应使用哪个数据源并根据请求返回适当的实例.工厂将此实例作为基类类型返回.

Answer 3

如果我理解正确-问题是，为什么我们同时具有Factory方法和抽象工厂模式。当不同的多态类具有不同的实例化过程时，您需要抽象工厂。而且，您希望某个模块创建实例并使用它们，而又不知道对象初始化的任何细节。例如-您想要创建进行一些计算的Java对象。但是其中一些是应用程序的一部分，而其他的字节码则应该从数据库中读取。另一方面-为什么我们需要工厂方法？同意，那个抽象工厂与它重叠。但是在某些情况下-编写的代码要少得多，具有更少的类和接口使系统更易于理解。

Answer 4

如果你看一下设计模式，几乎所有的设计模式都可以被冗余。但什么模式意味着解决类似类型问题的常用方法。设计模式为您提供了针对一组类似类型的设计问题的设计级别方法或解决方案。使用设计模式可以帮助您解决问题，从而更快地交付。