抽象工厂模式

介绍

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

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

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

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

不同颜色的多个正方形、圆形和椭圆形分别构成了三个不同的产品等级结构，而相同颜色的正方形、圆形和椭圆形构成了一个产品族，每一个形状对象都位于某个产品族，并属于某个产品等级结构。

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

抽象工厂模式示意图：

每一个具体工厂可以生产属于一个产品族的所有产品，例如生产颜色相同的正方形、圆形和椭圆形，所生产的产品又位于不同的产品等级结构中。如果使用工厂方法模式，图所示结构需要提供15个具体工厂，而使用抽象工厂模式只需要提供5个具体工厂，极大减少了系统中类的个数。

定义

抽象工厂模式为创建一组对象提供了一种解决方案。与工厂方法模式相比，抽象工厂模式中的具体工厂不只是创建一种产品，它负责创建一族产品。

提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。抽象工厂模式又称为Kit模式，它是一种对象创建型模式。

UML类图

角色

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

demo代码

在抽象工厂中声明了多个工厂方法，用于创建不同类型的产品，抽象工厂可以是接口，也可以是抽象类或者具体类，其典型代码如下所示：

abstract class AbstractFactory {  
public abstract AbstractProductA createProductA(); //工厂方法一  
public abstract AbstractProductB createProductB(); //工厂方法二  
……  
} 

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

class ConcreteFactory1 extends AbstractFactory {  
    //工厂方法一  
public AbstractProductA createProductA() {  
    return new ConcreteProductA1();  
}  
  
//工厂方法二  
public AbstractProductB createProductB() {  
    return new ConcreteProductB1();  
}  
  
……  
}

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

抽象工厂与工厂方法的比较

相同点

• 创建对象而不让客户知晓返回了什么确切的具体对象。

不同点

Cocoa框架中使用抽象工厂

1.NSNumber

创建各种类型的NSNumber对象

NSNumber *boolNumber = [NSNumber numberWithBool:YES]
NSNumber *IntNumber = [NSNumber numberWithInt:1]
NSNumber *floatNumber = [NSNumber numberWithFloat:1.0]
...

上面的方法返回的类型是NSCFBoolean和NSCFNumber。而且__NSCFNumber和__NSCFBoolean很明显是一个私有类。上面出现的这种现象在Foundation Framework中是很常见的一种情况，我们称作为类簇设计模式。那为什么要这样做呢？以NSNumber为例，我们知道NSNumber可以存储很多类型的数据，如int、Float、Double等等，具体支持哪些数据类型可以到NSNumber的头文件中查看，具体支持的类型如下：

char、unsigned char、short、unsigned short、int、unsigned int、long、unsigned long、long long、unsigned long long、float、double、BOOL、NSInteger、NSUInteger

一般情况下实现类似的效果一种方式是把NSNumber作为基类，然后分别去实现各自的子类，如下图所示：

但是一旦需要实现的子类多起来之后就会发现这样需要继承的子类太多，比如如果要仿NSNumber需要写这样十多个类。这对使用者来说显然不够方便，得记住这么多类。如果使用类簇，问题就变得简单了，把Number作为抽象基类，子类各自实现存取方式，然后在基类中定义多个初始化方式。NSNumber初始化伪代码如下：

- (id)initWithBool
{
    return [[__NSCFBoolean alloc]init];
}

- (id)initWithLong
{
    return [[__NSCFNumber alloc]init];
}

//...

xxxValue方法（intValue）

NSNumber为它的子类也提供一系列公有的接口，intValue、boolValue等

[boolNumber intValue];    // 返回1
[charNumber boolValue];   // 返回YES

boolNumber在内部保持布尔值YES，但仍然实现了公有的intValue方法，返回反映其内部布尔值的适当整数值。

类簇

类簇是基础框架中一种常见的设计模式，基于抽象工厂模式的思想，它将若干相关的私有具体工厂子类集合到一个公有的抽象超类之下。它是接口简单性和扩展性的权衡体现，在我们完全不知情的情况下，偷偷隐藏了很多具体的实现类，只暴露出简单的接口。例如，“数”包含了各种数值类型的完整集合，如字符、整数、浮点数和双精度数。这些数值类型是“数”的子集。所以NSNumber自然成为这些数子类型的超类型。NSNumber有一系列公有API，定义了各种类型的数所公有的行为。客户端使用时无需知道NSNumber实例的具体类型。

其他实现类簇的基础类有NSData、NSArray、NSDictionary、NSString

以抽象工厂模式的角度看NSNumber类簇

NSNumber是抽象工厂，定义一系列创建“数”（产品）的方法，如intValue、boolValue等。这些类型就是产品族（簇）。

NSCFBoolean和NSCFNumber是具体工厂类，重载了NSNumber中声明的公有工厂方法以生产产品。

2.NSArray类簇

    NSLog(@"%@", objc_getClass("NSArray"));                                     // NSArray
    NSLog(@"%@", NSStringFromClass([NSArray class]));                           // NSArray

    NSLog(@"%@", objc_getClass("NSMutableArray"));                              // NSMutableArray
    NSLog(@"%@", NSStringFromClass([NSMutableArray class]));                    // NSMutableArray

    NSArray *array1 = @[@"111", @"222", @"3333", @"4444"];
    NSLog(@"array1: %@", object_getClass(array1));                              // __NSArrayI

    NSArray *array2 = [@[@"111", @"222", @"3333", @"4444"] mutableCopy];
    NSLog(@"array2: %@", object_getClass(array2));                              // __NSArrayM

    id obj4 = [NSArray alloc];//注意: 得到的并不是NSArray类型的对象                 // __NSPlaceholderArray
    NSLog(@"obj4: %@", object_getClass(obj4));

    NSArray *array5 = [obj4 init];                                             // __NSArray0   数组没有元素
    NSLog(@"array5: %@", object_getClass(array5));

    NSMutableArray *obj6 = [NSMutableArray alloc];                             // __NSPlaceholderArray
    NSLog(@"array6: %@", object_getClass(obj6));

    NSMutableArray *array7 = [obj6 init];
    NSLog(@"array7: %@", object_getClass(array7));                            // __NSArrayM

我们使用NSArray不同情况得到的一个对象，其实根本不是NSArray类的对象，而是NSArray内部所管理的各种子类（__NSArray0、__NSArrayI、__NSArrayM）的对象 ，那么这样的作用 使用一个统一的入口类，来屏蔽内部各种各样的内部类.

3.使用类簇实现系统适配

#import "MyTool.h"

// 其他私有的不同系统版本的实现子类
// 我们可以把它写在 .m 中，而不必写成单独的 类文件
#import "MyTool_iOS6.h"
#import "MyTool_iOS7.h"
#import "MyTool_iOS8.h"

@implementation MyTool

// 判断当前系统版本，选择对应系统版本下的实现类
+ (instancetype)alloc {
    if (self == [MyTool class]) {
        if (floor(NSFoundationVersionNumber) <= NSFoundationVersionNumber_iOS_6_1) {
            //iOS6
            return [MyTool_iOS6 alloc];
        } else if (floor(NSFoundationVersionNumber) > NSFoundationVersionNumber_iOS_6_1 && floor(NSFoundationVersionNumber) < NSFoundationVersionNumber_iOS_8_0) {
            //iOS7
            return [MyTool_iOS7 alloc];
        } else if (floor(NSFoundationVersionNumber) > NSFoundationVersionNumber_iOS_7_1){
            //iOS8及以上
            return [MyTool_iOS8 alloc];
        }
    }
    return [super alloc];
}

- (void)doWork { /* 空实现，由具体子类去实现 */ }

@end

总结

优点

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

缺点

• 在抽象工厂模式中，增加新的产品族很方便，但是增加新的产品等级结构很麻烦，抽象工厂模式的这种性质称为“开闭原则”的倾斜性。
• 增加新的产品等级结构麻烦，需要对原有系统进行较大的修改，甚至需要修改抽象层代码，这显然会带来较大的不便，违背了“开闭原则”。

适用场景

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