没有一个答案能真正很好地解释抽象工厂——可能是因为这个概念是抽象的，而且在实践中使用较少。

考虑以下情况，可以举一个容易理解的例子。

你有一个系统，它与另一个系统相连接。我将使用Shalloway和Trott在《设计模式解释》(P194)中给出的例子，因为这种情况非常罕见，我想不出更好的例子了。在他们的书中，他们给出了本地硬件资源的不同组合的例子。他们举例说:

系统具有高分辨率显示和打印驱动程序 系统具有低分辨率显示和打印驱动程序

一个变量有两个选项(打印驱动程序、显示驱动程序)，另一个变量有两个选项(高分辨率、低分辨率)。我们希望以这样一种方式将它们耦合在一起，即我们有一个HighResolutionFactory和一个LowResolutionFactory，它们为我们生成正确类型的打印驱动程序和显示驱动程序。

这就是抽象工厂模式:

class ResourceFactory
{
    virtual AbstractPrintDriver getPrintDriver() = 0;

    virtual AbstractDisplayDriver getDisplayDriver() = 0;
};

class LowResFactory : public ResourceFactory
{
    AbstractPrintDriver getPrintDriver() override
    {
        return LowResPrintDriver;
    }

    AbstractDisplayDriver getDisplayDriver() override
    {
        return LowResDisplayDriver;
    }
};

class HighResFactory : public ResourceFactory
{
    AbstractPrintDriver getPrintDriver() override
    {
        return HighResPrintDriver;
    }

    AbstractDisplayDriver getDisplayDriver() override
    {
        return HighResDisplayDriver;
    }
};

我不会详细说明打印驱动程序和显示驱动程序的层次结构，只需要一个就足够演示了。

class AbstractDisplayDriver
{
    virtual void draw() = 0;
};

class HighResDisplayDriver : public AbstractDisplayDriver
{
    void draw() override
    {
        // do hardware accelerated high res drawing
    }
};

class LowResDisplayDriver : public AbstractDisplayDriver
{
    void draw() override
    {
        // do software drawing, low resolution
    }
};

为什么有效:

我们可以用一堆if语句来解决这个问题:

const resource_type = LOW_RESOLUTION;

if(resource_type == LOW_RESOLUTION)
{
    drawLowResolution();
    printLowResolution();
}
else if(resource_type == HIGH_RESOLUTION)
{
    drawHighResolution();
    printHighResolution();
}

现在我们可以这样做:

    auto factory = HighResFactory;
    auto printDriver = factory.getPrintDriver();
    printDriver.print();
    auto displayDriver = factory.getDisplayDriver();
    displayDriver.draw();

本质上——我们已经将运行时逻辑抽象到类的v-table中。

我对这种模式的看法是，它实际上并不是很有用。它把一些不需要结合的东西结合在一起。设计模式的重点通常是减少耦合，而不是增加耦合，因此在某些方面，此模式实际上是反模式，但在某些上下文中可能有用。

如果您到了认真考虑实现此功能的阶段，您可能会考虑一些替代设计。也许你可以编写一个返回工厂的工厂，工厂本身返回你最终想要的对象。我认为这将更加灵活，并且不会有相同的耦合问题。

附录:“四人帮”的例子也有类似的耦合。他们有一个MotifFactory和一个PMFactory。然后分别生成PMWindow, PMScrollBar和MotifWindow, MotifScrollBar。这是一个有点过时的文本，所以它可能很难理解上下文。我记得我读过这一章，从这个例子中除了有两个工厂基类的实现之外，我几乎没有理解什么，它们返回不同的对象族。

所有三种Factory类型都做同样的事情:它们是一个“智能构造函数”。

假设您希望能够创建两种水果:Apple和Orange。

工厂

Factory is "fixed", in that you have just one implementation with no subclassing. In this case, you will have a class like this:

class FruitFactory {

  public Apple makeApple() {
    // Code for creating an Apple here.
  }

  public Orange makeOrange() {
    // Code for creating an orange here.
  }

}

用例:在构造函数中构造Apple或Orange都太复杂了。

工厂方法

Factory method is generally used when you have some generic processing in a class, but want to vary which kind of fruit you actually use. So:

abstract class FruitPicker {

  protected abstract Fruit makeFruit();

  public void pickFruit() {
    private final Fruit f = makeFruit(); // The fruit we will work on..
    <bla bla bla>
  }
}

.．.然后你可以通过在子类中实现一个工厂方法来重用fruitpick . pickfruit()中的通用功能:

class OrangePicker extends FruitPicker {

  @Override
  protected Fruit makeFruit() {
    return new Orange();
  }
}

抽象工厂

Abstract factory is normally used for things like dependency injection/strategy, when you want to be able to create a whole family of objects that need to be of "the same kind", and have some common base classes. Here's a vaguely fruit-related example. The use case here is that we want to make sure that we don't accidentally use an OrangePicker on an Apple. As long as we get our Fruit and Picker from the same factory, they will match.

interface PlantFactory {
  
  Plant makePlant();

  Picker makePicker(); 

}

public class AppleFactory implements PlantFactory {
  Plant makePlant() {
    return new Apple();
  }

  Picker makePicker() {
    return new ApplePicker();
  }
}

public class OrangeFactory implements PlantFactory {
  Plant makePlant() {
    return new Orange();
  }

  Picker makePicker() {
    return new OrangePicker();
  }
}

这三种模式之间有什么不同?

工厂:创建对象时不向客户端公开实例化逻辑。

工厂方法:定义用于创建对象的接口，但让子类决定实例化哪个类。Factory方法允许类延迟实例化到子类

抽象工厂:提供一个接口，用于创建一系列相关或依赖的对象，而无需指定它们的具体类。

AbstractFactory模式使用组合将创建对象的责任委托给另一个类，而Factory方法设计模式使用继承并依赖于派生类或子类来创建对象

什么时候用哪个?

工厂:客户端只需要一个类，并不关心它得到的是哪个具体实现。

工厂方法:客户端不知道在运行时需要创建哪些具体的类，而只是想获得一个能够完成这项工作的类。

AbstactFactory:当您的系统必须创建多个产品系列，或者您希望提供一个产品库而不公开实现细节时。

抽象工厂类通常用工厂方法实现。工厂方法通常在模板方法中调用。

如果可能的话，还有与这些模式相关的java示例吗?

Factory和FactoryMethod

目的:

定义一个用于创建对象的接口，但是让子类来决定实例化哪个类。工厂方法允许类延迟实例化到子类。

UML diagram:

Product:它定义Factory方法创建的对象的接口。

ConcreteProduct:实现Product接口

创建者:声明Factory方法

ConcreateCreator:实现Factory方法以返回ConcreteProduct的实例

问题陈述:使用定义游戏界面的工厂方法创建游戏工厂。

代码片段:

工厂模式。什么时候使用工厂方法?

与其他创造模式的比较:

设计开始时使用工厂方法(不太复杂，更可定制，子类激增)，然后随着设计师发现需要更多灵活性的地方，逐步向抽象工厂、原型或构建器发展(更灵活，更复杂) 抽象工厂类通常使用工厂方法来实现，但它们也可以使用原型来实现

进一步阅读的参考资料:Sourcemaking设计模式

每个设计模式都努力确保编写的工作代码不受影响。我们都知道，一旦我们接触到工作代码，现有的工作流程中就会有缺陷，并且需要进行更多的测试以确保我们没有破坏任何东西。

工厂模式根据输入条件创建对象，从而确保你不需要编写如下代码:

 if (this) {
     create this kind of object 
 } else { 
     that kind of object 
 }

一个很好的例子就是旅游网站。旅游网站只能提供旅行(航班、火车、巴士)或/和提供酒店或/和提供旅游景点套餐。现在，当用户选择下一步时，网站需要决定需要创建什么对象。它是否也只创建travel或hotel对象?

现在，如果你设想在你的投资组合中添加另一个网站，并且你相信同样的核心可以被使用，例如，一个拼车网站，现在可以搜索出租车并在线支付，你可以在你的核心中使用一个抽象工厂。这样一来，你就可以再加入一个出租车和拼车工厂。

这两个工厂之间没有任何关系，所以把它们放在不同的工厂是一个很好的设计。

希望大家都明白了。再次研究这个网站，记住这个例子，希望它会有帮助。我真的希望我已经正确地表示了模式:)。

要回答这个问题，我可以参考《四人帮》一书。

书中没有“工厂”、“简单工厂”或“虚拟工厂”的定义。通常，当人们谈论“工厂”模式时，他们可能是在谈论创建类的特定对象的东西(但不是“构建器”模式);它们可能引用也可能不引用“工厂方法”或“抽象工厂”模式。任何人都可以实现“工厂”，但他不会，因为它不是一个正式的术语(请记住，一些人、公司、社区可以有自己的词汇表)。

本书只包含了“抽象工厂”和“工厂方法”的定义。

以下是书中的定义，并简要解释了为什么两者都如此令人困惑。我省略了代码示例，因为你可以在其他答案中找到它们:

工厂方法(GOF):定义一个用于创建对象的接口，但让子类来决定实例化哪个类。工厂方法允许类延迟实例化到子类。

抽象工厂(GOF):提供一个接口，用于创建相关或依赖的对象族，而无需指定它们的具体类。

Source of Confusion: Often, one can call a class that used in "Factory Method" pattern as "Factory". This class is abstract by definition. That's why it easy to call this class "Abstract Factory". But it's just the name of the class; you shouldn't confuse it with "Abstract Factory" pattern (class name != pattern name). The "Abstract Factory" pattern is different - it does not use an abstract class; it defines an interface (not necessarily a programming language interface) for creating parts of a bigger object or objects that are related to each other or must be created in a particular way.

没有人引用过原书《设计模式:可重用的面向对象软件的元素》，这本书在“创建模式的讨论”一节的前两段给出了答案:

There are two common ways to parameterize a system by the classes of objects it creates. One way is to subclass the class that creates the objects; this corresponds to using the Factory Method (107) pattern. The main drawback of this approach is that it can require a new subclass just to change the class of the product. Such changes can cascade. For example, when the product creator is itself created by a factory method, then you have to override its creator as well. The other way to parameterize a system relies more on object composition: Define an object that’s responsible for knowing the class of the product objects, and make it a parameter of the system. This is a key aspect of the Abstract Factory (87), Builder (97), and Prototype (117) patterns. All three involve creating a new “factory object” whose responsibility is to create product objects. Abstract Factory has the factory object producing objects of several classes. Builder has the factory object building a complex product incrementally using a correspondingly complex protocol. Prototype has the factory object building a product by copying a prototype object. In this case, the factory object and the prototype are the same object, because the prototype is responsible for returning the product.