IOS 设计模式 模板模式

转载:http://my.oschina.net/daguoshi/blog/486734?p={{totalPage}}

模板方法模式是面向对象软件设计中一种非常简单的设计模式。其基本思想是:定义一个操作中算法的骨架,而将一些步骤延迟到到子类中。模板方法使子类可以重定义算法的某些特定步骤而不改变算法的结构。


    在以下情形,应该考虑使用模板方法:

    @:需要一次性实现算法的不变部分,并将可变的行为留给子类来实现。

    @:子类的共同行为应该被提取出来放到公共类中,以避免代码重复。现有代码的差别应该被分离为新的操作。然后用一个调用这些操作的模板方法来替换这些不同的代码。

    @:需要控制子类的扩展。可以定义一个特定点调用“钩子”操作的模板方法。子类可以通过对钩子操作的实现在这些点扩展功能。

    钩子操作给出了默认行为,子类可对其进行扩展。默认行为通常什么都不做。子类可以重载这个方法,为模板方法提供附加的操作。

    模板方法模式中的控制结构流程是倒转的,因为父类的模板方法调用其子类的操作,而不是子类调用父类的操作。这与好莱坞原则类似:别给我们打电话,我们会打给你。

    模板方法会调用5中类型的操作:

    @:对具体类或客户端类的具体操作。

    @:对抽象类的具体操作。

    @:抽象操作。

    @:工厂方法

    @:钩子操作(可选的抽象操作)

    

    我们将对上一篇博客中的策略模式,两个验证策略相似的代码采用模板方法来进行实现。首先,我们要在InputValidator父类中,增加一个configValidateInfo的方法,这个用来配置验证的相关信息,具体的实现由其子类来进行实现。通过这样一个方法,就达到了把公共的算法给抽离出来,而不同的部分交给具体的子类去实现。为了保证验证算法的正常运行,我们就必须确保子类必须重写configValidateInfo方法,此时我们采取了抛出异常的机制,如果在其子类不重写该方法就抛出异常,从而保证了其子类必须实现。 另外,又增加了一个configExtraInfo的方法(这个就是钩子操作了,留给将来扩展使用)。

    InputValidator.h中InputValidator的声明

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
     #import <Foundation/Foundation.h>
#import <UIKit/UIKit.h>
 
static  NSString * const  InputValidationErrorDomain = @ "InputValidationErrorDomain" ;
 
@interface InputValidator : NSObject
 
/**
  *  这些属性的值,由其子类提供来进行配置的。
  */
@property (nonatomic, copy) NSString *regExpressPatter;
@property (nonatomic, copy) NSString *descriptionStr;
@property (nonatomic, copy) NSString *reason;
@property (nonatomic, assign) NSInteger errorCode;
 
/**
  *  实际验证策略的存根方法
  */
- ( BOOL )validateInput:(UITextField *)input error:(NSError *__autoreleasing *)error;
 
/**
  *  配置与验证相关的信息,这个要求子类必须重写,不进行重写的话,就抛出异常。
  */
- ( void )configValidateInfo;
 
/**
  *  配置一些额外的信息,留给将来扩展来使用。
  */
- ( void )configExtraInfo;
 
@end

    InputValidator.m中InputValidator类的实现

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
     #import  "InputValidator.h"
 
@implementation InputValidator
 
/**
  *  模板方法:把公共的部分给抽离出来,不同的部分(配置信息)交给子类去实现。
  */
- ( BOOL )validateInput:(UITextField *)input error:(NSError *__autoreleasing *)error {
     NSError *regError = nil;
     NSRegularExpression *regex = [NSRegularExpression regularExpressionWithPattern:_regExpressPatter options:NSRegularExpressionAnchorsMatchLines error:&regError];
     
     NSUInteger numberOfMatches = [regex numberOfMatchesInString:input.text options:NSMatchingAnchored range:NSMakeRange(0, input.text.length)];
     // 如果没有匹配,就会错误和NO.
     if  (numberOfMatches == 0) {
         if  (error != nil) {
             // 先判断error对象是存在的
             NSArray *objArray = [NSArray arrayWithObjects:_descriptionStr, _reason, nil];
             NSArray *keyArray = [NSArray arrayWithObjects:NSLocalizedDescriptionKey, NSLocalizedFailureReasonErrorKey, nil];
             
             NSDictionary *userInfo = [NSDictionary dictionaryWithObjects:objArray forKeys:keyArray];
             *error = [NSError errorWithDomain:InputValidationErrorDomain code:_errorCode userInfo:userInfo];  //错误被关联到定制的错误代码1001和在InputValidator的头文件中。
         }
         
         return  NO;
     }
     
     return  YES;
}
 
- ( void )configValidateInfo {
     // 必须要让子类进行重写,不进行重写就抛出异常的错误。
     [NSException  raise :NSInternalInconsistencyException format:@ "你必须重写InputValidator子类的configValidateInfo方法" ];
}
 
- ( void )configExtraInfo {
     // 预留接口,留给将来使用。
}

    

    现在父类InputValidator已经写好了,并且要求其子类必须实现configValidateInfo方法,我们先来看对数字进行验证的算法实现:

    NumberInputValidator.h中NumberInputValidator的类声明

?
1
2
3
4
5
6
7
     #import  "InputValidator.h"
 
@interface NumberInputValidator : InputValidator
 
- ( void )configValidateInfo;
 
@end

    NumberInputValidator.m中NumberInputValidator类的实现

?
1
2
3
4
5
6
7
8
9
10
11
12
     #import  "NumberInputValidator.h"
 
@implementation NumberInputValidator
 
- ( void )configValidateInfo {
     self.regExpressPatter = @ "^[0-9]*$" ;
     self.descriptionStr = NSLocalizedString(@ "验证失败" , @ "" );
     self.reason = NSLocalizedString(@ "输入仅能包含数字" , @ "" );
     self.errorCode = 1001;
}
 
@end

    写到这里,已经看出来了,在子类中不需要写同样的算法来实现其验证了,从而减少了代码的冗余 ,也遵循了同样的代码只维护一份的原则。对其字母进行验证的也是同样的道理,代码如下:

    AlphaInputValidator.h中AlphaInputValidator类的声明

?
1
2
3
4
5
6
7
     #import  "InputValidator.h"
 
@interface AlphaInputValidator : InputValidator
 
- ( void )configValidateInfo;
 
@end

    AlphaInputValidator.m中AlphaInputValidator类的实现

?
1
2
3
4
5
6
7
8
9
10
11
12
     #import  "AlphaInputValidator.h"
 
@implementation AlphaInputValidator
 
- ( void )configValidateInfo {
     self.regExpressPatter = @ "^[a-zA-Z]*$" ;
     self.descriptionStr = NSLocalizedString(@ "验证失败" , @ "" );
     self.reason = NSLocalizedString(@ "输入仅能包字母" , @ "" );
     self.errorCode = 1002;
}
 
@end

    

    至此,验证算法已经写完了,我们来看下在CustomTextField类中的实现,看看其发生了什么变化,如下:

    CustomTextField.h中CustomTextField中类的声明

?
1
2
3
4
5
6
7
8
9
     #import <UIKit/UIKit.h>
#import "InputValidator.h"
@interface CustomTextField : UITextField
 
@property (nonatomic, strong) InputValidator *inputValidator;  //用一个属性保持对InputValidator的引用。
 
- ( BOOL )validate;
 
@end

    CustomTextField.m中CustomTextField类的实现

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
     #import  "CustomTextField.h"
 
@implementation CustomTextField
 
- ( BOOL )validate {
     // 在这里调用该方法,对其不同的部分进行配置。
     [_inputValidator configValidateInfo];
     
     NSError *error = nil;
     BOOL  validationResult = [_inputValidator validateInput:self error:&error];
     
     if  (!validationResult) {
         UIAlertView *alertView = [[UIAlertView alloc]initWithTitle:[error localizedDescription] message:[error localizedFailureReason] delegate:nil cancelButtonTitle:@ "确定"  otherButtonTitles:nil, nil];
         [alertView show];
     }
     
     return  validationResult;
}
 
@end

    对于客户端的使用,还是和上篇的文章提到的一样的,而相对于上篇文章中的实现,本篇中采用模板算法把共同的部分给抽离出来放在父类中,而不同的部分交给子类去实现,这样减少了代码的冗余,也让后期代码维护起来更加容易,并且还提供了一些操作方法,以利于后期的扩展。(建议看这篇文章前,先把上一篇策略模式的文章给看下,这样或许更好理解些)。

    

    在框架设计中,模板方法模式相当常见。模板方法是代码复用的基本技术。通过它,框架的设计师可以把算法中应用程序相关的元素留给应用程序去实现。模板方法是抽出共同行为放入框架类中的手段。这一方式有助于提高可扩展性与可复用性,而维持各种类(框架类与用户类)之间的松耦合。Cocoa Touch框架也采用了模板方法模式,在框架中经常能看到这些框架类。

    如UIView类中的定制绘图:

    从iOS2.0开始,应用程序可以通过重写UIView类中的以下方法,执行定制绘图:

?
1
2
3
     - ( void )drawRect:(CGRect)rect {
 
}

    这个方法的默认实现什么也不做。UIView的子类如果真的需要绘制自己的视图,就重写这个方法。所以这个方法是钩子方法。

    当需要改变屏幕上的视图时,这个方法会被调用。框架会处理所有底层的苦差事,以实现这一点。由UIView处理的绘图过程的部分会调用drawRect:。如果这个方法中有代码,那么代码也会被调用。子类可以使用Quartz 2D函数UIGraphicsGetCurrentContext来取得当前图形上下文,用于在框架中提供任何2D元素。

    客户程序也可以通过调用以下UIView方法,手动激活绘图过程。

?
1
2
3
     - ( void )setNeedsDisplay {
 
}

    它通知UIView的实例重画屏幕上的整个矩形区域。也可以调用另一个实例方法,指定视图中特定矩形区域进行重画:

?
1
2
3
     - ( void )setNeedsDisplayInRect:(CGRect)rect {
 
}

    rect会标记指定的区域,就是说只有这个区域被重画,其他地方不会被重画。

    

    这就是模板方法了。

    完整demo链接地址:https://github.com/guoshimeihua/StrategyDemo

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
1、 IOS设计模式的六大设计原则之单一职责原则(SRP,Single Responsibility Principle) 定义   就一个类而言,应该仅有一个引起它变化的原因。 定义解读   这是六大原则中最简单的一种,通俗点说,就是不存在多个原因使得一个类发生变化,也就是一个类只负责一种职责的工作。 优点 类的复杂度降低,一个类只负责一个功能,其逻辑要比负责多项功能简单的多; 类的可读性增强,阅读起来轻松; 可维护性强,一个易读、简单的类自然也容易维护; 变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。 问题提出   假设有一个类C,它负责两个不同的职责:职责P1和P2。当职责P1需求发生改变而需要修改类C时,有可能会导致原本运行正常的职责P2功能发生故障。 解决方案   遵循单一职责原则。分别建立两个类C1、C2,使C1完成职责P1,C2完成职责P2。这样,当修改类C1时,不会使职责P2发生故障风险;同理,当修改C2时,也不会使职责P1发生故障风险。   说到这里,大家会觉得这个原则太简单了。稍有经验的程序员,即使没有听说过单一职责原则,在设计软件时也会自觉的遵守这一重要原则。在实际的项目开发中,谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单,并且被认为是常识,即便是经验丰富的程序员写出的程序,也会有违背这一原则的代码存在。为什么会出现这种现象呢?因为有职责扩散。实际项目中,因为某种原因,职责P被分化为粒度更细的职责P1和P2。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值