简介

工厂方法模式通过引入工厂等级结构，解决了简单工厂模式中工厂类职责太重的问题，但由于工厂方法模式中的每个工厂只生产一类产品，可能会导致系统中存在大量的工厂类，势必会增加系统的开销。此时，可以考虑将一些相关的产品组成一个 "产品族"，由同一个工厂来统一生产，这就是抽象工厂模式的基本思想。

比如，对于一款桌面应用，现在需要设计一套界面皮肤库，不同的皮肤将提供视觉效果不同的按钮、文本框、组合框等界面元素，为此采用工厂方法模式来进行系统的设计，为了保证系统的灵活性和可扩展性，提供一系列具体工厂来创建按钮、文本框、组合框等界面元素，客户端针对抽象工厂编程，初始结构如图所示:

在上图中，提供了大量工厂来创建具体的界面组件，可以通过配置文件更换具体界面组件从而改变界面风格。但是，此设计方案存在以下问题：

1. 当需要增加新的皮肤时，虽然不需要修改现有代码，但是需要增加大量类，针对每一个新增具体组件都需要增加一个具体工厂，类的个数成对增加，这无疑会导致系统越来越庞大，从而增加了系统的维护成本和运行开销。
2. 由于同一种风格的具体界面组件通常要一起显示，因此需要为每个组件都选择一个具体工厂，用户在使用时必须逐个进行设置，如果某个具体工厂选择失误将会导致界面显示混乱，虽然可以适当增加一些约束语句，但客户端代码和配置文件都较为复杂。

显然，工厂方法模式无法解决这两个问题。唯有抽象工厂方法模式可以解决该问题。

产品等级结构与产品族

在工厂方法模式中，具体工厂负责生产具体的产品，每一个具体工厂对应一种具体产品，工厂方法具有唯一性，一般情况下，一个具体工厂中只有一个或者一组重载的工厂方法。但是，有时候希望一个工厂可以提供多个产品对象，而不是单一的产品对象，例如一个电器工厂，它可以生产电视机、电冰箱、空调等多种电器，而不是只生产某一种电器。为了更好地
理解抽象工厂模式，需要引入两个概念：

1. 产品等级结构。产品等级结构即产品的继承结构，例如一个抽象类是电视机，其子类有海尔电视机、海信电视机、T℃L电视机，则抽象电视机与具体品牌的电视机之间构成了一个产品等级结构，抽象电视机是父类，而具体品牌的电视机是其子类。
2. 产品族。在抽象工厂模式中，产品族是指由同一个工厂生产的位于不同产品等级结构中的一组产品，例如海尔电器工厂生产的海尔电视机、海尔电冰箱，海尔电视机位于电视机产品等级结构中，海尔电冰箱位于电冰箱产品等级结构中，海尔电视机、海尔电冰箱构成了一个产品族。

产品等级结构与产品族示意图如图所示：

如图，不同颜色的多个正方形、圆形和椭圆形分别构成了 3 个不同的产品等级结构，而相同颜色的正方形、圆形和椭圆形构成了一个产品族，每一个形状对象都位于某个产品族，并属于某个产品等级结构。上图中一共有 5 个产品族，分属于 3 个不同的产品等级结构。只要指明一个产品所处的产品族以及它所属的等级结构，就可以唯一确定这个产品。

当系统所提供的工厂所生产的具体产品并不是一个简单地对象，就可以使用抽象工厂模式。抽象工厂模式是所有形式的工厂模式中最为抽象和最具一般性的一种形式。抽象工厂模式与工厂方法模式最大的区别在于，工厂方法模式针对的是一个产品等级结构，而抽象工厂模式需要面对多个产品等级结构，一个工厂等级结构可以负责多个不同产品等级结构中的产品对象的创建。当一个工厂等级结构可以创建出分属于不同产品等级结构的一个产品族中的所有对象时，抽象工厂模式比工厂方法模式更为简单、高效。

抽象工厂模式概述

抽象工厂模式为创建一组对象提供了一种解决方法，与工厂方法模式相比，抽象工厂模式中的具体工厂不只是创建一种产品，它负责创建一族产品。抽象工厂模式定义如下：提供一个创建一些列相关或相互依赖对象的接口，而无需指定它们具体的类。抽象工厂模式又称为 Kit 模式，它是一种对象创建型模式。

在抽象工厂模式中，每一个具体工厂都提供了多个工厂方法用于产生多种不同类型的产品，这些产品构成一个产品族。其结构图如图所示：

其中，包含如下 4 个角色：

1. AbstractFactory(抽象工厂)：它声明了一组用于创建一族产品的方法，每一个方法对应一种产品；
2. ConcreteFactory(具体工厂)：它实现了在抽象工厂中声明的创建产品的方法，生成一组具体产品，这些产品构成了一个产品族，每一个产品都位于某个产品等级结构中；
3. AbstractProduct(抽象产品)：它为每种产品声明结构，在抽象产品中声明了产品所具有的业务方法；
4. ConcreteProduct(具体产品)：它定义具体工厂生产的具体产品对象，实现在抽象产品接口中声明的业务方法；

抽象工厂的典型代码如下：

class AbstractFactory {
public:
  virtual AbstractProductA* createProductA() = 0;
  virtual AbstractProductB* createProductB() = 0;
};

具体工厂实现了抽象工厂，每一个具体的工厂方法可以返回一个特定的产品对象，而同一个具体工厂所创建的产品对象构成了一个产品族。对于每一个具体工厂类，其典型代码如下：

class ConcreteFactory1 : public AbstractFactory {
public:
  virtual AbstractProductA* createProductA() override;
  virtual AbstractProductB* createProductB() override;
};

与工厂方法模式一样，抽象工厂模式也可以为每一种产品提供一组重载的工厂方法，以不同的方式创建产品对象。

注意，抽象工厂模式最大缺点就是在抽象工厂模式中增加新的产品族很方便，但是增加新的产品等级结构却很麻，抽象工厂模式的这种性质称为开闭原则的倾斜性。

总结

优点

1. 抽象工厂模式隔离了具体类的生成，使得客户并不需要知道什么被创建。由于这种隔离，更换一个具体工厂就变得相对容易，所有的具体工厂都实现了在抽象工厂中声明的那些公共接口，因此只需改变具体工厂的实例，就可以在某种程度上改变整个软件系统的行为。
2. 当一个产品族中的多个对象被设计成一起工作时，它能够保证客户端始终只使用同一个产品族中的对象。
3. 增加新的产品族很方便，无须修改已有系统，符合开闭原则。

缺点

增加新的产品等级结构麻烦，需要对原有系统进行较大的修改，甚至需要修改抽象层代码，这显然会带来较大的不便，违背了开闭原则。

适用场景

1. 一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有类型的工厂模式都是很重要的，用户无须关心对象的创建过程，将对象的创建和使用解耦。
2. 系统中有多于一个的产品族，而每次只使用其中某一产品族。可以通过配置文件等方式来使得用户可以动态改变产品族，也可以很方便地增加新的产品族。
3. 属于同一个产品族的产品将在一起使用，这一约束必须在系统的设计中体现出来。同一个产品族中的产品可以是没有任何关系的对象，但是它们都具有一些共同的约束。例如同一操作系统下的按钮和文本框，按钮与文本框之间没有直接关系，但它们都是属于某一操作系统的，此时具有一个共同的约束条件：操作系统的类型。
4. 产品等级结构稳定，设计完成之后，不会向系统中增加新的产品等级结构或者删除已有的产品等级结构。

所有代码见 Kohirus-Github