码迷,mamicode.com
首页 > 其他好文 > 详细

工厂模式三部曲:工厂方法模式

时间:2016-04-27 09:24:20      阅读:220      评论:0      收藏:0      [点我收藏+]

标签:

前言

 

紧接着上一篇文章开始写,这是本系列中的第二篇文章了,这篇文章主要讲一下工厂方法模式。在最后一篇抽象工厂模式的文章中,将会对这三篇文章进行一次总结。

 

这篇文章中并没有给出反射机制实现的代码,主要是因为工厂方法模式就是为了解决简单工厂模式的一些缺点,然而使用了反射机制的简单工厂模式已经不具备这些缺点,所以就不需要这篇文章中讲的内容了。这篇文章主要还是单一从设计模式的角度来讲一下这个模式,带大家认识一下这个设计模式。

 

本人理解可能不够深刻,这一系列文章中存在的问题,欢迎大家提出,谢谢!

 


 

什么是工厂方法模式?

 

工厂方法模式和简单工厂模式十分类似,大致结构是基本类似的。不同在于工厂方法模式对工厂类进行了进一步的抽象,将之前的一个工厂类抽象成了抽象工厂和工厂子类,抽象工厂定义一个创建抽象子类的接口,抽象工厂的子类实现这些接口并决定实例化哪个抽象子类。工厂子类决定着创建哪个抽象子类,外界决定着创建哪种工厂子类,抽象子类和工厂子类是一一对应的。

 

在工厂方法模式中,和简单工厂模式一样,对外隐藏了抽象子类的创建过程,外界只需要关心工厂类即可,负责实例化的工厂子类决定着最后的结果。

 

工厂方法模式主要包含四部分:

 

  • 工厂抽象类:定义创建抽象子类的接口,通过接口返回具体的抽象子类。

  • 工厂子类:继承自工厂抽象类,并重写父类的方法来创建对应的抽象子类。

  • 抽象类:定义抽象子类所需的属性和方法,子类通过继承自抽象类获得这些方法。

  • 抽象子类:继承自抽象类,实现具体的操作。

 

为什么要用工厂方法模式?

 

在简单工厂模式的代码中,如果我们没有使用反射机制,只是标准的简单工厂模式代码。会有一个问题,就是如果新增加其他运算功能,需要创建一个抽象子类,但是还需要修改工厂类中的代码逻辑,这种设计是不符合开放封闭原则的。开放封闭原则对于修改是关闭的,对于扩展是开放的。而且将所有的操作子类的判断和实例化都由一个工厂类完成,如果业务比较复杂会导致工厂类负担较重。

 

工厂方法模式将之前负责生成具体抽象子类的工厂类,抽象为工厂抽象类和工厂子类组成的一系列类。每创建一个抽象子类,就需要创建一个工厂子类,并且一一对应,由工厂子类去生成对应的抽象子类,由外界使用方来决定生成哪个工厂子类。这样在增加新的需求时,就不需要对工厂抽象类进行修改,而是对应新增的抽象子类创建对应的工厂子类即可。

 

业务场景

 

这里的业务场景还用之前简单工厂模式中提到的运算的例子,根据运算符的不同,计算两个值的结果。

 

UML类图

 

技术分享

工厂方法模式

 

这张类图中增加了很多工厂子类,每一个抽象子类都对应着一个工厂子类。这样做的好处就是更佳灵活,每次新添加一个抽象子类,就生成一个工厂子类,对其他类没有任何影响。

 

简单工厂模式违背了开放封闭原则,每次添加和删除抽象子类的时候,都需要对工厂类进行操作,这样不仅对工厂类的扩展开放了,还开放了工厂类的修改,这就是违背开放封闭原则的。因为按照开放封闭原则,新增加一个需求,应该是在原有类的基础上进行扩展,而不是对原有类进行修改。这样整个模式在生成新算法类时,只是进行扩展而不对模式中原有的代码进行修改,这就是符合开放封闭原则的。

 

代码实现

 

工厂方法模式新建一个抽象子类时,选择算法的操作还是存在的,外界的灵活性依然存在,只是将原来由工厂类对抽象子类的创建,交给工厂子类去完成创建。之前增加和删除修改的是工厂类,现在是增加工厂子类,这也是开放封闭原则的一个体现。之前的简单工厂是在工厂类中创建抽象子类,工厂方法模式在工厂子类中创建抽象子类,依然封装了对象实例化的过程。

 

由于代码比较多,所以这里只贴出加法和减法运算的代码,其他运算代码类似。

 

创建运算抽象类,声明参与运算的两个属性和运算方法,下面的具体抽象子类继承自这个类。

 

@interface Operation : NSObject

@property (nonatomic, assign) CGFloat numberOne;

@property (nonatomic, assign) CGFloat numberTwo;

- (CGFloat)getResult;

@end

 

@implementation Operation

- (CGFloat)getResult {

    return 0;

}

@end

 

@interface OperationAdd : Operation

@end

 

@implementation OperationAdd

- (CGFloat)getResult {

    return self.numberOne + self.numberTwo;

}

@end

 

@interface OperationSub : Operation

@end

 

@implementation OperationSub

- (CGFloat)getResult {

    return self.numberOne - self.numberTwo;

}

@end

 

抽象工厂类,定义了实例化实际运算类的方法,由子类继承并实例化不同的运算类。

 

@interface Factory : NSObject

+ (Operation *)CreateOperation;

@end

 

@implementation Factory

+ (Operation *)CreateOperation {

    return nil;

}

@end

 

@interface FactoryAdd : Factory

@end

 

@implementation FactoryAdd

+ (Operation *)CreateOperation {

    return [OperationAdd new];

}

@end

 

@interface FactorySub : Factory

@end

 

@implementation FactorySub

+ (Operation *)CreateOperation {

    return [OperationSub new];

}

@end

 

外界使用时,直接实例化某个工厂子类即可,通过外界实例化某个工厂子类来选择具体的运算类。

 

- (void)viewDidLoad {

    Operation *oper = [FactoryAdd CreateOperation];

    oper.numberOne = 13;

    oper.numberTwo = 24;

    NSLog(@"result : %f", [oper getResult]);

}

 

当需求发生改变时,需要进行算法的切换,外界只需要将工厂子类调用类方法的类名换一下即可,其他地方都不用发生变化。这样做就像一个“开关”一样,在外界由这个工厂子类的类型控制着抽象子类的实例化类型,而我们并不知道抽象子类实例化的过程。

 

工厂方法模式的优缺点

 

优点

 

工厂方法模式的的优点在于更大的灵活性,增加或删除某种运算都不会对其他地方造成影响,更佳符合开放封闭原则。

 

而且对抽象的使用更佳深入,将工厂类也抽象为了抽象工厂类和工厂子类,外界调用更加灵活,这也是对多态的一种体现。

 

缺点

 

工厂方法模式的缺点也是非常显而易见的,工厂方法模式中新增一个抽象子类,意味着工厂子类要跟着成对增加,这样会造成生成过多的类,工厂方法模式的复杂度也会随之增加。

 

对于这个缺点,反射机制当然可以很好的解决这个问题,工厂设计模式和反射机制的配合,可以使这种设计模式更佳易用和灵活,减少了条件判断和类的数量。

 

答疑解惑

 

使用工厂方法模式,看上去会感觉到这不是更麻烦了吗,直接在外界创建具体的抽象子类不行吗?还用这么麻烦的创建工厂子类,然后再用工厂子类去创建抽象子类。

 

我将从两方面回答这个问题:

 

  1. 假设现在项目比较大,在外界很多地方都直接使用了抽象子类直接进行运算,这种方式在写代码的时候确实很快也很爽。但是,假设有一天,产品经理过来说要改需求,我现在不要加减乘除这四种运算了,我要换成更高级的其他运算。。。如果这样改起来改动就大了,需要把所有直接使用抽象子类实例化的地方都做修改。

  2. 这只是一种设计模式的思路,在程序的开发中没有一种设计模式是万能的,在适合的地方用适合的设计模式,或根据业务需求自己制定一套模式,这才是最好的。只有最适合业务的模式,才是最好的模式。

工厂模式三部曲:工厂方法模式

标签:

原文地址:http://www.cnblogs.com/fengmin/p/5437479.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!