详解iOS应用开发中使用设计模式中的抽象工厂模式

概述

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

定义

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

最初的定义出现于《设计模式》(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,这样,很明显是违背“开放-关闭原则”。这也是可以理解的,没有任何一个设计模式是完美没有瑕疵的,这就好比世界上没有打不败的武功一样。我们可以做的就是在实际的需求中,尽可能的将变化点进行隔离,以达到变化发生的时候,对整个系统的影响最小,变化所带来的变更和成本最低。

示例

先给大家看一下数据库访问的类结构图吧。

好的,简单分析一下上面这张类结构图,这张图中有三个独立的模块儿,一个是IFactory接口,以不同数据库为划分原则对部门进行抽象,一个是对访问数据库的不同部门,还有一个是对数据库操作的人员进行了抽象。类图中没有提到接下来需要给大家展示的两个类,一个是User类,一个是Department类,因为这两个类是对数据库数据的封装,和结构并没有直接关系,所以没有显示出来,在此说明一下,以免大家引起混乱。其实,静下心来细细的看,结构还是蛮清晰的。

呵呵,下面还是老样子,给大家展示一下代码。

注意:本文所有代码均在ARC环境下编译通过。

User类接口

代码如下:

#import <Foundation/Foundation.h>

@interface User :NSObject
@property int *ID;
@property NSString *Name;
@end

User类实现

代码如下:

#import "User.h"

@implementation User
@synthesize Name =_Name;
@synthesize ID =_ID;
@end

Department类接口

代码如下:

#import <Foundation/Foundation.h>

@interface Department:NSObject
@property int *ID;
@property NSString *DeptName;
@end

Department类实现

代码如下:

#import "Department.h"

@implementation Department
@synthesize ID =_ID;
@synthesize DeptName =_DeptName;
@end

IDepartment类接口

代码如下:

#import <Foundation/Foundation.h>

@class Department;
@interface IDepartment :NSObject
-(void)Insert:(Department*)department;
-(Department*)GetDepartment:(int)myId;
@end

IDepartment类实现

代码如下:

#import "IDepartment.h"
#import "Department.h"

@implementation IDepartment
-(void)Insert:(Department *)department{
    return;
}
-(Department*)GetDepartment:(int)myId{
    return nil;
}
@end

SqlserverDepartment类接口

代码如下:

#import "IDepartment.h"

@interface SqlserverDepartment:IDepartment
@end

SqlserverDepartment类实现

代码如下:

#import "SqlserverDepartment.h"

@implementation SqlserverDepartment
-(void)Insert:(Department *)department{
    NSLog(@"在SQL Server中给Department表增加一条记录");
}
-(Department*)GetDepartment:(int)myId{
    NSLog(@"在SQL Server中根据ID得到Department表一条记录");
    return nil;
}
@end

AccessDepartment类接口

代码如下:

#import "IDepartment.h"

@interface AccessDepartment:IDepartment
@end

*AccessDepartment类实现

代码如下:

#import "AccessDepartment.h"

@implementation AccessDepartment
-(void)Insert:(Department *)department{
    NSLog(@"在Access中给Department表增加一条记录");
}
-(Department*)GetDepartment:(int)myId{
    NSLog(@"在Access中根据myId得到Department表一条记录");
    return nil;
}
@end

IUser类接口

代码如下:

#import <Foundation/Foundation.h>

@class User;
@interfaceIUser :NSObject
-(void)Insert:(User*)user;
-(User*)GetUser:(int)myID;
@end

IUser类实现

代码如下:

#import "IUser.h"
#import "User.h"

@implementation IUser
-(void)Insert:(User *)user{
    return;
}
-(User*)GetUser:(int)myID{
    return nil;
}
@end

SqlServerUser类接口

代码如下:

#import "IUser.h"

@interface SqlServerUser :IUser
@end
SqlServerUser类实现

#import "SqlServerUser.h"

@implementation SqlServerUser
-(void)Insert:(User *)user{
    NSLog(@"在SQL Server中给User表增加一条记录");
}
-(User*)GetUser:(int)myID{
    NSLog(@"在SQL Server中根据myID得到User表一条记录");
    return nil;
}
@end

AccessUser类接口

代码如下:

#import "IUser.h"

@interface AccessUser :IUser
@end

AccessUser类实现

代码如下:

#import "AccessUser.h"

@implementation AccessUser
-(void)Insert:(User *)user{
    NSLog(@"在Access中给User表增加一条记录");
}
-(User*)GetUser:(int)myID{
    NSLog(@"在Access中根据myID得到User表一条记录");
    return nil;
}
@end

IFactories类接口

代码如下:

#import "AccessUser.h"

@implementation AccessUser
-(void)Insert:(User *)user{
    NSLog(@"在Access中给User表增加一条记录");
}
-(User*)GetUser:(int)myID{
    NSLog(@"在Access中根据myID得到User表一条记录");
    return nil;
}
@end

IFactories类实现

代码如下:

#import "IFactories.h"
#import "IUser.h"
#import "IDepartment.h"

@implementation IFactories
-(IUser*)CreateUser{
    return nil;
}
-(IDepartment*)CreateDepartment{
    return nil;
}
@end

AccessFactory类接口

代码如下:

#import "IFactories.h"

@interface AccessFactory :IFactories
@end

AccessFactory类实现

代码如下:

#import "AccessFactory.h"
#import "AccessUser.h"
#import "AccessDepartment.h"

@implementation AccessFactory
-(IUser*)CreateUser{
    return [[AccessUser alloc]init];
}
-(IDepartment*)CreateDepartment{
    return [[AccessDepartment alloc]init];
}
@end

SqlServerFactory类接口

代码如下:

#import "IFactories.h"

@interface SqlServerFactory :IFactories
@end

SqlServerFactory类实现

代码如下:

#import "SqlServerFactory.h"
#import "SqlServerUser.h"
#import "SqlserverDepartment.h"

@implementation SqlServerFactory
-(IUser*)CreateUser{
    return [[SqlServerUser alloc]init];
}
-(IDepartment*)CreateDepartment{
    return [[SqlserverDepartment alloc]init];
}
@end

Main方法调用

代码如下:

#import <Foundation/Foundation.h>
#import "User.h"
#import "Department.h"
#import "IFactories.h"
#import "AccessFactory.h"
#import "IUser.h"
#import "IDepartment.h"

int main (int argc,const char * argv[])
{
    @autoreleasepool{
        User *user = [[User alloc]init];
        Department *dept = [[Department alloc]init];
        IFactories *factories = [[AccessFactory alloc]init];
        IUser *iu = [factories CreateUser];
        [iu Insert:user];
        [iu GetUser:1];

IDepartment *myId = [factories CreateDepartment];
        [myId Insert:dept];
        [myId GetDepartment:1];
    }
    return 0;
}

上面罗列了一堆代码,其实,罗列这些代码的目的只有一个,就是为了帮助像我一样基础不太好的同学尽快入门,有一个感性的认识,迈过第一道门槛。

时间: 2016-03-28

解析iOS应用开发中对设计模式中的抽象工厂模式的实现

概述 抽象工厂模式是对象的创建模式,它是工厂方法模式的进一步推广. 假设一个子系统需要一些产品对象,而这些产品又属于一个以上的产品等级结构.那么为了将消费这些产品对象的责任和创建这些产品对象的责任分割开来,可以引进抽象工厂模式.这样的话,消费产品的一方不需要直接参与产品的创建工作,而只需要向一个公用的工厂接口请求所需要的产品. 通过使用抽象工厂模式,可以处理具有相同(或者相似)等级结构中的多个产品族中的产品对象的创建问题.如下图所示: 根据产品角色的结构图,就不难给出工厂角色的结构设计图. 可以

设计模式开发中的备忘录模式在iOS应用开发中的运用实例

何为备忘录模式? 在响应某些事件时,应用程序需要保存自身的状态,比如当用户保存文档或程序退出时.例如,游戏退出之前,可能需要保存当前会话的状态,如游戏等级.敌人数量.可用武器的种类等.游戏再次打开时,玩家可以从离开的地方接着玩.很多时候,保存程序的状态真的不需要什么特别巧妙的方法.任何简单有效的方法都可以,但是同时,保存信息应该只对原始程序有意义.原始程序应该是能够解码它所保存文档中的信息的唯一实体.这就是备忘录模式应用于游戏.文字处理等程序的软件设计中的方式,这些程序需要保存当前上下文的复杂状

举例讲解设计模式中的原型模式在iOS应用开发中的作用

1 前言 在许多面向对象的应用程序中,有些对象的创建代价过于大或者过于复杂.要是可以重建相同的对象并作轻微的改动,事情会容易许多.我们可以通过轻微的改动重用已有的对象,以适应程序中的特定情况.今天我们就来学习一下该模式. 2 详述 2.1 定义 应用于"复制"操作的模式成为原型(Prototype)模式.复制(cloning)指用同一模具生产一系列的产品.模具所基于的物品称为原型.尽管产品是用同一模具复制的,但是某些属性,如颜色与尺寸,可以稍有不同,但是他们还是属于同一类. 2.2 何

详解iOS App设计模式开发中对于享元模式的运用

享元模式的概念 在面向对象软件设计中,利用公共对象不仅能节省资源还能提高性能.共享的对象只能提供某些内在的信息,而不能用来识别对象.专门用于设计可共享对象的一种设计模式叫做享元模式(Flyweight pattern). 实现享元模式需要两个关键组件,通常是可共享的享元对象和保存他们的池.某种中央对象维护这个池,并从它返回适当的实例. 运用共享技术有效地支持大量细粒度的对象. 公共交通(如公共汽车)已有一百多年的历史了.大量去往相同方向的乘客可以分担保有和经营车辆(如公共汽车)的费用.公共汽车有

iOS App设计模式开发中对interpreter解释器模式的运用

解释器模式 今天和大家分享的模式是解释器模式. 首先介绍一下解释器模式适合解决哪类问题. 其实,解释器模式需要解决的问题是,如果一种特定类型的问题发生的频率足够高,那么可能就值得将该问题的各个实例表述为一个简单语言的句子.这样就可以构建一个解释器,该解释器通过解释这些句子来解决该问题. 就应用的例子来说,例如正则表达式就是它的一种具体应用,解释器可以为正则表示定义一个文法,如何表示一个特定的正则表达式,以及如何解释这个正则表达式. 解释器模式的类结构图如下. 图中的结构也比较好理解,解释器方法抽

iOS App的设计模式开发中对State状态模式的运用

1.概述 在软件开发过程中,应用程序可能会根据不同的情况作出不同的处理.最直接的解决方案是将这些所有可能发生的情况全都考虑到.然后使用if... ellse语句来做状态判断来进行不同情况的处理.但是对复杂状态的判断就显得"力不从心了".随着增加新的状态或者修改一个状体(if else(或switch case)语句的增多或者修改)可能会引起很大的修改,而程序的可读性,扩展性也会变得很弱.维护也会很麻烦.那么我就考虑只修改自身状态的模式. 例子1:按钮来控制一个电梯的状态,一个电梯开们,

实例解析设计模式中的外观模式在iOS App开发中的运用

外观模式(Facade),为子系统中的一组接口提供一个一致的界面,此模式定义 一个高层接口,这个接口使得这一子系统更加容易使用. 下面给大家展示一下类的结构图,想必大家一看就明白了: 其实这个模式中,没有类与类之间的继承关系,只是进行了简单的类引用,统一了对外的接口而已.看起来是不是很简单?废话不多说了,下面简单向大家展示一下代码吧! 注意:本文所有代码均在ARC环境下编译通过. SubSystemOne类接口 复制代码 代码如下: #import <Foundation/Foundation.

深入解析设计模式中的装饰器模式在iOS应用开发中的实现

装饰器模式可以在不修改代码的情况下灵活的为一对象添加行为和职责.当你要修改一个被其它类包含的类的行为时,它可以代替子类化方法. 一.基本实现 下面我把类的结构图向大家展示如下: 让我们简单分析一下上面的结构图,Component是定义一个对象接口,可以给这些对象动态地添加职责.ConcreteComponent是定义了一个具体的对象,也可以给这个对象添加一些职责.Decorator,装饰抽象类,继承了Component,从外类来扩展Component类的功能,但对于Component来说,是无需

iOS App设计模式开发中对迭代器模式的使用示例

何为迭代器模式? 迭代器提供了一种顺序访问集合对象中元素的方法,而无需暴漏结构的底层表示和细节.遍历集合中元素的职能从集合本身转移到迭代器对象.迭代器定义了一个用于访问集合元素并记录当前元素的接口.不同的迭代器可以执行不同的策略. 例子 说了这么多,下面给大家展示一下类关系图. 上图中Client的右边是迭代器,左边是具体迭代的类型,在迭代器内部对具体需要迭代的类型进行了引用,还算不难理解吧,呵呵.其实,看起来是为了对具体类型进行解耦.好啦,下面给出具体的代码实现,简单的模拟了迭代器模式. 注意

iOS App设计模式开发中对建造者模式的运用实例

定义          "将一个复杂对象的构建与它的表现分离,使得同样的构建过程可以创建不同的表现". 看这个概念,可能感觉很是抽象,能看懂但是不知道有什么用.我们打一个比方来理解上面的定义.打比方之前,咱们先来聊聊这个设计模式是干什么用的?我们为什么要用这个模式呢?建造者模式负责将构建复杂对象的过程和它的部件解耦,也就是过程和部件的解耦.比如说汽车,是一个很复杂的对象,它有很多的部件,车轮.发动机.座椅.车门.油箱等等:它的组装过程也很复杂(需要专业人士按步骤进行装配),建造者模式就

iOS App设计模式开发中策略模式的实现示例

这次介绍一下策略模式(Strategy Pattern),相比之下是一种比较简单的模式.它也叫政策模式(Policy Pattern). 策略模式使用的就是面向对象的继承和多态机制,其他的没有什么玄机.策略模式适合使用在: 1. 多个类只有在算法或行为上稍有不同的场景. 2. 算法需要自由切换的场景. 3. 需要屏蔽算法规则的场景. 使用策略模式当然也有需要注意的地方,那么就是策略类不要太多,如果一个策略家族的具体策略数量超过4个,则需要考虑混合模式,解决策略类膨胀和对外暴露问题.在实际项目中,

深入解析C#设计模式编程中对建造者模式的运用

示例 我们先来以这样一个场景引入:  在电脑城装机总有这样的经历.我们到了店里,先会有一个销售人员来询问你希望装的机器是怎么样的配置,他会给你一些建议,最终会形成一张装机单.和客户确定了装机配置以后,他会把这张单字交给提货的人,由他来准备这些配件,准备完成后交给装机技术人员.技术人员会把这些配件装成一个整机交给客户. 不管是什么电脑,它总是由CPU.内存.主板.硬盘以及显卡等部件构成的,并且装机的过程总是固定的: 把主板固定在机箱中 把CPU安装到主板上 把内存安装到主板上 把硬盘连接到主板上

详解JavaScript设计模式开发中的桥接模式使用

桥接模式将抽象部分与实现部分分离开来,使两者都可以独立的变化,并且可以一起和谐地工作.抽象部分和实现部分都可以独立的变化而不会互相影响,降低了代码的耦合性,提高了代码的扩展性. 按照GoF的定义,桥接模式的作用在于"将抽象与其实现隔离开来,以便二者独立变化".这种模式对于Javascript中常见的事件驱动的编程大有裨益. 桥接模式最常见和实际的应用场合之一是事件监听器回调函数. example:事件监听器,把事件处理的语句封装到回调函数中,通过接口而不是实现进行编程. 基本理论 桥接

讲解Java设计模式编程中的建造者模式与原型模式

建造者模式 定义 又叫生成器模式,它可以将复杂对象的建造过程抽象出来(抽象类别),使这个抽象过程的不同实现方法可以构造出不同表现(属性)的对象. 当创建复杂对象的算法应该独立于该对象的组成部分时,而且构造过程必须允许被构造的对象有不同的表示时.我们可以考虑使用建造者模式. 实现 1. Builder为创建一个Product对象的各个部件指定抽象接口.通常包含创建产品和返回产品的抽象方法,也可以是具体方法,把创建过程放到ConcreteBuilder类中. 2. ConcreteBuilder 实

iOS应用设计模式开发中对简单工厂和工厂方法模式的运用

简单工厂模式 正如此模式的名称一样,简单工厂模式基本上是所有设计模式里最简单的一种,类与类之间的关系一目了然.这次我就用很多地方经常举的例子--计算器,来说明这个模式.首先给大家展示一下类之间的结构图: 通过这张结构图,可以清晰的看到,加法类.减法类.乘法类.除法类继承自运算类,简单工厂类依赖于运算类的实例化来实现相应的运算功能,好的,看起来并不复杂,让我们直接展示一下代码吧(鉴于目前点点不支持Objective C的代码高亮,所以就直接写啦,尽量保持整齐吧.另,为了照顾像我一样基础不是很好的同