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" ; @interfaceInputValidator:NSObject /** *这些属性的值，由其子类提供来进行配置的。 */ @property(nonatomic,copy)NSString*regExpressPatter; @property(nonatomic,copy)NSString*descriptionStr; @property(nonatomic,copy)NSString*reason; @property(nonatomic,assign)NSIntegererrorCode; /** *实际验证策略的存根方法 */ -( BOOL )validateInput:(UITextField*)inputerror:(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" @implementationInputValidator /** *模板方法：把公共的部分给抽离出来，不同的部分（配置信息）交给子类去实现。 */ -( BOOL )validateInput:(UITextField*)inputerror:(NSError*__autoreleasing*)error{ NSError*regError=nil; NSRegularExpression*regex=[NSRegularExpressionregularExpressionWithPattern:_regExpressPatteroptions:NSRegularExpressionAnchorsMatchLineserror:&regError]; NSUIntegernumberOfMatches=[regexnumberOfMatchesInString:input.textoptions:NSMatchingAnchoredrange:NSMakeRange(0,input.text.length)]; //如果没有匹配，就会错误和NO. if (numberOfMatches==0){ if (error!=nil){ //先判断error对象是存在的 NSArray*objArray=[NSArrayarrayWithObjects:_descriptionStr,_reason,nil]; NSArray*keyArray=[NSArrayarrayWithObjects:NSLocalizedDescriptionKey,NSLocalizedFailureReasonErrorKey,nil]; NSDictionary*userInfo=[NSDictionarydictionaryWithObjects:objArrayforKeys:keyArray]; *error=[NSErrorerrorWithDomain:InputValidationErrorDomaincode:_errorCodeuserInfo:userInfo]; //错误被关联到定制的错误代码1001和在InputValidator的头文件中。 } return NO; } return YES; } -( void )configValidateInfo{ //必须要让子类进行重写，不进行重写就抛出异常的错误。 [NSException raise :NSInternalInconsistencyExceptionformat:@ "你必须重写InputValidator子类的configValidateInfo方法" ]; } -( void )configExtraInfo{ //预留接口，留给将来使用。 }

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

NumberInputValidator.h中NumberInputValidator的类声明

?

1 2 3 4 5 6 7

#import "InputValidator.h" @interfaceNumberInputValidator:InputValidator -( void )configValidateInfo; @end

NumberInputValidator.m中NumberInputValidator类的实现

?

1 2 3 4 5 6 7 8 9 10 11 12

#import "NumberInputValidator.h" @implementationNumberInputValidator -( 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" @interfaceAlphaInputValidator:InputValidator -( void )configValidateInfo; @end

AlphaInputValidator.m中AlphaInputValidator类的实现

?

1 2 3 4 5 6 7 8 9 10 11 12

#import "AlphaInputValidator.h" @implementationAlphaInputValidator -( 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" @interfaceCustomTextField: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" @implementationCustomTextField -( BOOL )validate{ //在这里调用该方法，对其不同的部分进行配置。 [_inputValidatorconfigValidateInfo]; NSError*error=nil; BOOL validationResult=[_inputValidatorvalidateInput:selferror:&error]; if (!validationResult){ UIAlertView*alertView=[[UIAlertViewalloc]initWithTitle:[errorlocalizedDescription]message:[errorlocalizedFailureReason]delegate:nilcancelButtonTitle:@ "确定" otherButtonTitles:nil,nil]; [alertViewshow]; } 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