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

大部分的定义是这样的:

抽象工厂提供一个 界面创建家庭的 相关对象，而不指定 他们的具体课程

抽象工厂模式的作用是什么，因为我们可以通过创建具体类本身的对象来完成任务。为什么我们有一个工厂方法，创建具体类的对象？

请提供任何我必须实现抽象工厂模式的实际例子？

88773 次浏览
小开

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

小开

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

小开

抽象工厂是 依赖注入(DI)的一个非常核心的设计模式。这里是一个堆栈溢出问题的列表，其中抽象工厂的应用程序已经被 接受作为解决方案。

据我所知，这些问题代表了人们真正关心的问题，所以你应该从一些现实生活中的例子开始:

小开

使用抽象工厂模式的一个实际例子是提供对两个不同数据源的数据访问。假设您的应用程序支持不同的数据存储区。(例如 SQL 数据库和 XML 文件)。您有两个不同的数据访问接口，例如 IReadableStore和 IWritableStore，它们定义应用程序所期望的公共方法，而不管所使用的数据源的类型如何。

应该使用哪种类型的数据源不应该改变客户端代码检索其数据访问类的方式。您的 AbstractDataAccessFactory知道配置了哪种类型的数据源，并为客户机代码提供 < em > 混凝土厂 ，即 SqlDataAccessFactory或 XmlDataAccessFactory。这些具体的工厂可以创建具体的实现，例如 SqlReadableStore和 SqlWriteableStore。

NETFramework 中的 DbProviderFactory就是这种模式的一个例子。

小开

很简单，想象你有一个与抽象一起工作的代码，你应该创建抽象而不是具体的类。

您应该总是针对抽象工作，因为您可以更好地修改代码。

这是一个很好的例子: Http://en.wikipedia.org/wiki/abstract_factory_pattern#c.23

小开

我发现抽象工厂模式被高估了。

首先，有一组需要实例化的 相互关联类型并不经常发生在 那个中。

其次，在使用依赖注入时，接口提供的间接(抽象)级别通常已经足够。

例如，WindowsGUVS MacGUVS... 你有一个 WindowsButton，MacButton，WindowsScrollBar，MacScrollbar 等等，通过定义 混凝土按钮，滚动条等，使用访问者和/或解释器模式来提供实际行为，通常更容易实现。

小开

为了直接回答您的问题，您可能不需要使用这样的设计模式。

然而，请记住，现实世界中的大多数项目都是不断发展的，您希望提供某种可扩展性，以便使您的项目不受未来的影响。

根据我自己的经验，大多数情况下，工厂是实现的，随着项目的增长，它会变成更复杂的设计模式，比如抽象工厂。

小开

抽象工厂非常适合支持多个平台，同时保持代码库的统一。假设您有一个大的 Qt 或 GTK + 或。NET/Mono 程序，您希望在 Windows、 Linux 和 OSX 上运行该程序。但是您有一个在每个平台上以不同方式实现的特性(可能通过 kernel32API 或 POSIX 特性)。

public abstract class Feature
{
public abstract int PlatformSpecificValue { get; }


public static Feature PlatformFeature
{
get
{
string platform;
// do platform detection here
if (platform == "Win32")
return new Win32Feature();
if (platform == "POSIX")
return new POSIXFeature();
}
}


// platform overrides omitted
}

使用这个抽象工厂，您的 UI 不需要了解当前平台的任何内容。

Feature feature = Feature.PlatformFeature;
Console.WriteLine(feature.PlatformSpecificValue);
小开

都是依赖关系。如果您不关心紧密耦合和依赖性，那么就不需要抽象工厂。但是，只要您编写了需要维护的应用程序，这就很重要了。

小开

假设您创建了 a.jar，而其他人使用了您的 jar 并希望在您的代码中使用一个新的具体对象。如果您不使用抽象工厂，那么她必须修改您的代码或覆盖您的代码。但是如果您使用的是抽象工厂，那么她可以提供一个工厂并传递给您的代码，一切都很好。

改进版本: 考虑下面这种情况: 其他人编写了一个框架。该框架使用一个抽象工厂和一些具体工厂在运行时创建大量对象。因此，您可以轻松地将自己的工厂注册到现有框架中，并创建自己的对象。由于抽象的工厂模式，该框架接近于修改，并且仍然易于扩展。

小开

抽象工厂模式的作用是什么，因为我们可以通过创建具体类本身的对象来完成任务。为什么我们有一个工厂方法，创建具体类的对象？

在没有 抽象工厂的情况下，客户端需要知道具体类的详细信息。这种紧密耦合已经与 抽象工厂一起被移除。

现在，工厂法公开了一个客户端必须使用的契约。可以通过添加新产品向工厂添加更多产品，这些产品实现了 Factory Method 公开的接口。

为了更好地理解，请参考以下相关的 SE 问题:

工厂模式和抽象工厂模式的基本区别是什么？

意图:

提供创建相关或依赖对象家族的接口，而不指定它们的具体类。

您可以从这篇 源头挖掘文章中了解 抽象工厂模式的 意图、结构、核对表及经验法则。

清单:

  1. 确定 平台独立性和创建服务是否是当前痛苦的来源。
  2. 画出 平台和 产品的矩阵。
  3. 定义一个由每个产品的工厂方法组成的 工厂接口。
  4. 为封装对新操作符的所有引用的每个平台定义一个 工厂派生类。
  5. 客户应该退出对 new 的所有引用，并使用 工厂方法创建 产品对象。
小开

当客户端不知道时，这种模式特别有用 准确地创建什么样的类型。例如，让我们说一个陈列室 专门销售手机的智能手机会受到质疑 这里我们不知道要创建的对象的确切类型 (假设手机的所有信息都以 但是我们知道我们正在寻找智能手机 是由三星制造的。这些信息实际上可以 使用，如果我们的设计有抽象的工厂实施。

C # 中抽象工厂模式的理解与实现

小开

我认为在实例化非常复杂的地方，应该有一个抽象的工厂模式，而不是简单的工厂模式, 对于单个工厂来说太复杂和丑陋，对于 UI 来说太复杂以至于无法理解。

假设这是一个 TYPE _ A 品牌，而不是一个单一的类。.假设有100种类似的 A 类类型，您需要从它们中实例化一个对象。 想象一下，有一个详细的复杂的信息需要，以使正确的对象出品牌的许多类似类型的对象，在这个对象实体，你需要知道确切的参数调整，以及如何调整他们。

在这个品牌的专用工厂里，我们会让他们进行区分，得到确切的实例化对象，以及如何实例化它。我们将知道根据从网络(让我们说什么颜色在线商店可用)的输入，以及从其他应用程序和服务运行在后台(参数的 UI 不知道他们)。

也许明天我们会有另一个家族，比如 type _ B 和 type _ C 来实例化。 因此 UI 将有“ if else”来知道用户是否需要一个“ type _ A”，“ type _ B”或“ type _ C”——但是工厂类将确切地决定从类型(来自系列)中构建哪个类，以及如何调优它——什么值应该设置为它的参数，或者发送给它的承包商。所有这些——根据 UI 不知道的许多参数。 所有这些对于一个工厂类来说都太多了。

小开

抽象工厂或者任何工厂都是为了解决同样的问题而存在的，即“对象创建的抽象”。

它通常抽象出以下内容:

  1. 决定实例化哪个对象的 if条件。
  2. new运算符，对象的实例化。

简而言之，工厂的责任就是这样。

您可以通过 这个获得详细的解释。


提交答案