IOS设计模式浅析之抽象工厂模式(Abstract Factory)
概述
在前面两章中,分别介绍了简单工厂模式和工厂方法模式,我们知道简单工厂模式的优点是去除了客户端与具体产品的依赖,缺点是违反了“开放-关闭原则”;工厂方法模式克服了简单工厂模式的缺点,将产品的创建工作放到具体的工厂类,每个工厂类负责生成一个产品。但是在实际应用中,一个工厂类只创建单个产品的情况很少,一般一个工厂类会负责创建一系列相关的产品,如果我们要设计这样的系统,工厂方法模式显然不能满足应用的需求,本章要介绍的抽象工厂模式,可以很好地解决一系列产品创建的问题。
定义
“提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。”
- 最初的定义出现于《设计模式》(Addison-Wesley,1994)。
结构图
先对上面结构图的几个角色进行说明:
- 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,这样,很明显是违背“开放-关闭原则”。这也是可以理解的,没有任何一个设计模式是完美没有瑕疵的,这就好比世界上没有打不败的武功一样。我们可以做的就是在实际的需求中,尽可能的将变化点进行隔离,以达到变化发生的时候,对整个系统的影响最小,变化所带来的变更和成本最低。
示例
还是继续简单工厂模式和工厂方法模式的应用场景,这里将场景稍微改变一下:我们知道,绘制统计图形的方案有多种,我们既可以使用OWC来绘制统计图形,也可以使用HTML 5来绘制统计图形,或者其他的一些第三方插件来进行绘图,等等。这里我们用OWC和HTML 5绘制统计图形来说明抽象工厂模式(注意:示例和场景只是为了说明设计模式的思想,并不是说实际开发中我们就会这么使用)。先来看看新应用场景使用抽象工厂模式实现的结构图:
根据结构图,我们来看看部分源码(完整代码在后面会提供下载)。
AbstractLine.h:
@protocol AbstractLine <NSObject> - (void)drawLine;
AbstractPie.h:
@protocol AbstractPie <NSObject> - (void)drawPie;
AbstractFactory.h:
@protocol AbstractFactory <NSObject> - (id<AbstractLine>)createLine;
- (id<AbstractPie>)createPie;
客户端调用代码:
id<AbstractFactory> factory = [[[HTML5Factoryalloc] init] autorelease];
// id<AbstractFactory> factory = [[[OWCFactory alloc] init] autorelease];
id<AbstractLine> line = [factory createLine];
id<AbstractPie> pie = [factory createPie]; [line drawLine];
[pie drawPie];
从调用代码我们可以看到抽象工厂的两个优点:
- 能够很方便的变换产品系列;
- 具体的创建实例过程与客户端分离,客户端是通过它们的抽象接口操作实例,产品的具体类名也被具体工厂的实现分离,不会出现在客户代码中。
抽象工厂模式的缺点我们前面也分析了:在新加产品的需求下,违背开放-封闭原则。通过优缺点的比较,我们可以在如下场景下使用抽象工厂模式:功能模块已经非常成熟,基本上不需要太多修改,但是有可能会替换掉实现这些功能模块的类的那种情况。比如说数据库链接,所有的JDBC功能模块几乎一样,只不过种类有所不同,有些是SQL-Server,有些是Oracle,那么这时候用抽象工厂来实现,面对更换数据库的情况,就比较方便了。
【小思考】:从上面的客户端调用代码看到,如果有多处变换产品系列的地方,我们需要每处都进行修改,这样的话,实际上也没有达到我们的效果:应对变化,尽可能少的修改代码。那么该怎样处理这种情况呢?解决方案可以参看工厂方法模式中的思考小节。
抽象工厂模式&建造者模式
抽象工厂模式和建造者模式都属于创建型模式,它们在对象创建方面存在许多相似之处。但是,两者也存在较大的区别,具体如下:
建造者模式 |
抽象工厂模式 |
构建复杂对象 |
构建简单或复杂对象 |
以多个步骤构建对象 |
以单一步骤构建对象 |
以多种方式构建对象 |
以单一方式构建对象 |
在构建过程的最后一步返回产品 |
立刻返回产品 |
专注一个特定产品 |
强调一套产品 |
抽象工厂模式&工厂方法模式
工厂方法模式只有一个抽象产品类,而抽象工厂模式有多个;工厂方法模式中工厂类一般只有一个方法,创建一种产品;抽象工厂模式中工厂类一般有多个方法,创建一系列产品。
可以这么来理解:工厂方法模式是一种极端情况的抽象工厂模式,而抽象工厂模式可以看成是工厂方法模式的一种推广。
最新文章
- MDT部署中命令行脚本的使用。
- 不要迷恋那些没技术含量的Linux发行版
- solaris知识库
- SQL_从星期一到星期六自动打卡SQL代码
- PAT-乙级-1002. 写出这个数 (20)
- Unit Testing PowerShell Code with Pester
- Oracle中包的创建
- COM组件开发实践(七)---多线程ActiveX控件和自动调整ActiveX控件大小(上)
- Week8(10月31日):并发
- C#简单验证并限制登录次数小示例
- Couchbase 中的分布式储存
- Linux库函数制作(静态库、动态库)
- python空字典列表两种生成方式对赋值带来的不同影响
- 删除表中重复行SQL
- OO第二次博客作业—17373247
- npm run dev--The &#39;mode&#39; option has not been set, webpack will fallback to &#39;production&#39; for this value
- java.lang.IllegalStateException: Cannot forward after response has been committed的一个情况解决方法
- Git同步远程fork的项目
- centos7下安装docker(12docker网络)
- HTML5自定义data属性
热门文章
- jvm-监控指令-jdump
- How to enable Hibernate option in windows 2008 R2 server?
- RabbitMQ,Apache的ActiveMQ,阿里RocketMQ,Kafka,ZeroMQ,MetaMQ,Redis也可实现消息队列,RabbitMQ的应用场景以及基本原理介绍,RabbitMQ基础知识详解,RabbitMQ布曙
- C#断点续传
- HBase集群的安装部署
- Block系列2:Block内存管理
- SRS Audio Sandbox没有声音怎么办
- FileZilla_Server如何配置
- 使用OpenSSL生成CSR文件,并申请全球通用SSL证书
- 经典SQL语句使用方法大全