IOS设计模式浅析之抽象工厂模式(Abstract Factory)

灰太狼 2021-12-23 18:07 190阅读 0赞

概述

在前面两章中，分别介绍了[简单工厂模式][Link 1]和[工厂方法模式][Link 2]，我们知道[简单工厂模式][Link 1]的优点是去除了客户端与具体产品的依赖，缺点是违反了“[开放\-关闭原则][-]”；[工厂方法模式][Link 2]克服了[简单工厂模式][Link 1]的缺点，将产品的创建工作放到具体的工厂类，每个工厂类负责生成一个产品。但是在实际应用中，一个工厂类只创建单个产品的情况很少，一般一个工厂类会负责创建一系列相关的产品，如果我们要设计这样的系统，[工厂方法模式][Link 2]显然不能满足应用的需求，本章要介绍的抽象工厂模式，可以很好地解决一系列产品创建的问题。

定义

**　　“提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。”**

*  最初的定义出现于《设计模式》(Addison-Wesley,1994)。

结构图

![18083859-1d122ad2f42b4aff944f48a02c487557.png][]

先对上面结构图的几个角色进行说明：

*  AbstractFactory：抽象工厂接口，里面应该包含所有产品创建的抽象方法；
 *  ConcreteFactory1和ConcreteFactory2：具体的工厂，创建具有特定实现的产品对象；
 *  AbstractProductA和AbstractProductB：抽象产品，它们可能有多种不同的实现方式；
 *  ProductA1、ProductA2、ProductB1和ProductB2：具体的产品，是抽象产品的具体实现。

从结构图中可以看到，抽象工厂方法最大的好处是能够很**方便的变换产品系列**(例如id<AbstractFactory> factory =\[ \[ConcreteFactory1 alloc\] init\]，只需要将ConcreteFactory1换成ConcreteFactory2，就可以创建ProductA2和ProductB2)。另外，**抽象工厂方法让具体的创建实例过程与客户端分离，客户端是通过它们的抽象接口操作实例，产品的具体类名也被具体工厂的实现分离，不会出现在客户代码中**(例如id<AbstractProductA> product = \[factory createProductA\]，客户端根本不知道具体的类名是ProductA1还是ProductA2)。

但是，抽象工厂方法也是存在缺点的，比如说现在我们要增加一个新的产品，首先，我们需要增加三个类：AbstractProductC、ProductC1、ProductC2；另外，我们还需要更改三个类：AbstractFactory、ConcreteFactory1、ConcreteFactory2，这样，很明显是违背“[开放\-关闭原则][-]”。这也是可以理解的，没有任何一个设计模式是完美没有瑕疵的，这就好比世界上没有打不败的武功一样。我们可以做的就是在实际的需求中，尽可能的将变化点进行隔离，以达到变化发生的时候，对整个系统的影响最小，变化所带来的变更和成本最低。

示例

还是继续[简单工厂模式][Link 1]和[工厂方法模式][Link 2]的应用场景，这里将场景稍微改变一下：我们知道，绘制统计图形的方案有多种，我们既可以使用OWC来绘制统计图形，也可以使用HTML 5来绘制统计图形，或者其他的一些第三方插件来进行绘图，等等。这里我们用OWC和HTML 5绘制统计图形来说明抽象工厂模式(**注意：示例和场景只是为了说明设计模式的思想，并不是说实际开发中我们就会这么使用**)。先来看看新应用场景使用抽象工厂模式实现的结构图：

![18084235-6648a47568f7458fa573529f1f19a9a2.png][]

根据结构图，我们来看看部分源码(完整代码在后面会提供下载)。

AbstractLine.h：

1 @protocol AbstractLine <NSObject>
 2 
 3 - (void)drawLine;

AbstractPie.h：

1 @protocol AbstractPie <NSObject>
 2 
 3 - (void)drawPie;

AbstractFactory.h：

1 @protocol AbstractFactory <NSObject>
 2 
 3 - (id<AbstractLine>)createLine;
 4 - (id<AbstractPie>)createPie;

客户端调用代码：

1 id<AbstractFactory> factory = [[[HTML5Factoryalloc] init] autorelease];
 2 // id<AbstractFactory> factory = [[[OWCFactory alloc] init] autorelease];
 3 id<AbstractLine> line = [factory createLine];
 4 id<AbstractPie> pie = [factory createPie];
 5 
 6 [line drawLine];
 7 [pie drawPie];

从调用代码我们可以看到抽象工厂的两个优点：

*  能够很方便的变换产品系列；
 *  具体的创建实例过程与客户端分离，客户端是通过它们的抽象接口操作实例，产品的具体类名也被具体工厂的实现分离，不会出现在客户代码中。

抽象工厂模式的缺点我们前面也分析了：在新加产品的需求下，违背开放\-封闭原则。通过优缺点的比较，我们可以在如下场景下使用抽象工厂模式：功能模块已经非常成熟，基本上不需要太多修改，但是有可能会替换掉实现这些功能模块的类的那种情况。比如说数据库链接，所有的JDBC功能模块几乎一样，只不过种类有所不同，有些是SQL-Server，有些是Oracle，那么这时候用抽象工厂来实现，面对更换数据库的情况，就比较方便了。

【小思考】：从上面的客户端调用代码看到，如果有多处变换产品系列的地方，我们需要每处都进行修改，这样的话，实际上也没有达到我们的效果：应对变化，尽可能少的修改代码。那么该怎样处理这种情况呢？解决方案可以参看[工厂方法模式][Link 2]中的思考小节。

[源码下载][Link 3]

抽象工厂模式**&**建造者模式

抽象工厂模式和建造者模式都属于创建型模式，它们在对象创建方面存在许多相似之处。但是，两者也存在较大的区别，具体如下：

<table> 
 <tbody> 
 <tr> 
 <td> 建造者模式 </td> 
 <td> 抽象工厂模式 </td> 
 </tr> 
 <tr> 
 <td> 构建复杂对象 </td> 
 <td> 构建简单或复杂对象 </td> 
 </tr> 
 <tr> 
 <td> 以多个步骤构建对象 </td> 
 <td> 以单一步骤构建对象 </td> 
 </tr> 
 <tr> 
 <td> 以多种方式构建对象 </td> 
 <td> 以单一方式构建对象 </td> 
 </tr> 
 <tr> 
 <td> 在构建过程的最后一步返回产品 </td> 
 <td> 立刻返回产品 </td> 
 </tr> 
 <tr> 
 <td> 专注一个特定产品 </td> 
 <td> 强调一套产品 </td> 
 </tr> 
 </tbody> 
</table>

抽象工厂模式**&**工厂方法模式

[工厂方法模式][Link 2]只有一个抽象产品类，而抽象工厂模式有多个；[工厂方法模式][Link 2]中工厂类一般只有一个方法，创建一种产品；抽象工厂模式中工厂类一般有多个方法，创建一系列产品。

可以这么来理解：[工厂方法模式][Link 2]是一种极端情况的抽象工厂模式，而抽象工厂模式可以看成是[工厂方法模式][Link 2]的一种推广。

[返回目录][Link 4]

转载于:https://www.cnblogs.com/eagle927183/p/3479644.html

[Link 1]: http://www.cnblogs.com/eagle927183/p/3472865.html
[Link 2]: http://www.cnblogs.com/eagle927183/p/3477876.html
[-]: http://www.cnblogs.com/eagle927183/p/3455180.html
[18083859-1d122ad2f42b4aff944f48a02c487557.png]: /images/20211223/82138718936547b1850cda49f4f268e5.png
[18084235-6648a47568f7458fa573529f1f19a9a2.png]: /images/20211223/e1e4ef7386b940fcbc6e0906da8dc1b6.png
[Link 3]: http://pan.baidu.com/s/1jCpkG
[Link 4]: http://www.cnblogs.com/eagle927183/p/3447956.html