iOS应用运用设计模式中的Strategy策略模式的开发实例
在写程序的时候，我们经常会碰到这样的场景：把一堆算法塞到同一段代码中，然后使用if-else或switch-case条件语句来决定要使用哪个算法？这些算法可能是一堆相似的类函数或方法，用以解决相关的问题。比如，一个验证输入数据的例程，数据本身可以是任何数据类型（如NSString、CGFloat等），每种数据类型需要不同的验证算法。如果能把每个算法封装成一个对象，那么就能消除根据数据类型决定使用什么算法的一堆if-else或switch-case语句。
我们把相关算法分离为不同的类，称为策略模式。策略模式：定义一系列算法，把它们一个个封装起来，并且使它们可相互替换。本模式使得算法可独立于使用它的客户端而变化。
在以下情形下，我们应该考虑使用策略模式。
@：一个类在其操作中，使用多个条件语句来定义许多行为，我们可以把相关的条件分支移到它们自己的策略类中。
@：需要算法的各种变体。
@：需要避免把复杂的、与算法相关的数据结构暴漏给客户端。
我们用一个简单的例子来说明以下，策略模式是怎么使用的。假设有两个UITextField，一个UITextField只能输入字母，另一个UITextField只能输入数字，为了确保输入的有效性，我们需要在用户结束文本框的编辑时做下验证。我们把数据验证放在代理方法textFieldDidEndEdting中。
如果不使用策略模式，我们的代码会写成这样：
-(void)textFieldDidEndEditing:(UITextField*)textField{
if(textField==self.numberTF){
//验证其值只包含数字
}elseif(textField==self.alphaTF){
//验证其值只包含字母
}
}
要是有更多不同类型的文本框，条件语句还会继续下去。如果能去掉这些条件语句，代码会更容易管理，将来对代码的维护也会容易许多。
现在的目标是把这些验证检查提到各种策略类中，这样他们就能在代理方法和其他方法之中重用。每个验证都从文本框取出输入值，然后根据所H需的策略进行验证，最后返回一个BOOL值。如果返回失败，还会返回一个NSError实例。返回的NSError可以解释失败的原因。
我们设计一个抽象基类InputValidator，里面有一个validateInput:inputerror:error方法。分别有两个子类NumberInputValidator、AlphaInputValidator。具体的代码如下所示：
InputValidator.h中抽象InputValidator的类声明
staticNSString*constInputValidationErrorDomain=@"InputValidationErrorDomain"; @interfaceInputValidator:NSObject /** * 实际验证策略的存根方法 */ -(BOOL)validateInput:(UITextField*)inputerror:(NSError*__autoreleasing*)error; @end
这个方法还有一个NSError指针的引用，当有错误发生时（即验证失败），方法会构造一个NSError实例，并赋值给这个指针，这样使用验证的地方就能做详细的错误处理。
InputValidator.m中抽象InputValidator的默认实现
#import"InputValidator.h"
@implementationInputValidator
-(BOOL)validateInput:(UITextField*)inputerror:(NSError*__autoreleasing*)error{
if(error){
*error=nil;
}
returnNO;
}
@end
我们已经定义了输入验证器的行为，然后我们要编写真正的输入验证器了，先来写数值型的，如下：
NumberInputValidator.h中NumberInputValidator的类定义
#import"InputValidator.h" @interfaceNumberInputValidator:InputValidator /** * 这里重新声明了这个方法，以强调这个子类实现或重载了什么，这不是必须的，但是是个好习惯。 */ -(BOOL)validateInput:(UITextField*)inputerror:(NSError*__autoreleasing*)error; @end
NumberInputValidator.m中NumberInputValidator的实现
#import"NumberInputValidator.h"
@implementationNumberInputValidator
-(BOOL)validateInput:(UITextField*)inputerror:(NSError*__autoreleasing*)error{
NSError*regError=nil;
NSRegularExpression*regex=[NSRegularExpressionregularExpressionWithPattern:@"^[0-9]*$"options:NSRegularExpressionAnchorsMatchLineserror:®Error];
NSUIntegernumberOfMatches=[regexnumberOfMatchesInString:input.textoptions:NSMatchingAnchoredrange:NSMakeRange(0,input.text.length)];
//如果没有匹配，就会错误和NO.
if(numberOfMatches==0){
if(error!=nil){
//先判断error对象是存在的
NSString*description=NSLocalizedString(@"验证失败",@"");
NSString*reason=NSLocalizedString(@"输入仅能包含数字",@"");
NSArray*objArray=[NSArrayarrayWithObjects:description,reason,nil];
NSArray*keyArray=[NSArrayarrayWithObjects:NSLocalizedDescriptionKey,NSLocalizedFailureReasonErrorKey,nil];
NSDictionary*userInfo=[NSDictionarydictionaryWithObjects:objArrayforKeys:keyArray];
//错误被关联到定制的错误代码1001和在InputValidator的头文件中。
*error=[NSErrorerrorWithDomain:InputValidationErrorDomaincode:1001userInfo:userInfo];
}
returnNO;
}
returnYES;
}
@end
现在，我们来编写字母验证的实现，代码如下：
AlphaInputValidator.h中AlphaInputValidator的类定义
#import"InputValidator.h" @interfaceAlphaInputValidator:InputValidator -(BOOL)validateInput:(UITextField*)inputerror:(NSError*__autoreleasing*)error; @end
AlphaInputValidator.m中AlphaInputValidator的实现:
#import"AlphaInputValidator.h"
@implementationAlphaInputValidator
-(BOOL)validateInput:(UITextField*)inputerror:(NSError*__autoreleasing*)error{
NSError*regError=nil;
NSRegularExpression*regex=[NSRegularExpressionregularExpressionWithPattern:@"^[a-zA-Z]*$"options:NSRegularExpressionAnchorsMatchLineserror:®Error];
NSUIntegernumberOfMatches=[regexnumberOfMatchesInString:input.textoptions:NSMatchingAnchoredrange:NSMakeRange(0,input.text.length)];
//如果没有匹配，就会错误和NO.
if(numberOfMatches==0){
if(error!=nil){
//先判断error对象是存在的
NSString*description=NSLocalizedString(@"验证失败",@"");
NSString*reason=NSLocalizedString(@"输入仅能包字母",@"");
NSArray*objArray=[NSArrayarrayWithObjects:description,reason,nil];
NSArray*keyArray=[NSArrayarrayWithObjects:NSLocalizedDescriptionKey,NSLocalizedFailureReasonErrorKey,nil];
NSDictionary*userInfo=[NSDictionarydictionaryWithObjects:objArrayforKeys:keyArray];
*error=[NSErrorerrorWithDomain:InputValidationErrorDomaincode:1002userInfo:userInfo];//错误被关联到定制的错误代码1002和在InputValidator的头文件中。
}
returnNO;
}
returnYES;
}
@end
AlphaInputValidator也是实现了validateInput方法的InputValidator类型。它的代码结构和算法跟NumberInputValidator相似，只是使用了不同的正则表达式，不同错误代码和消息。可以看到两个版本的代码有很多重复。两个算法结构相同，我们可以把这个结构，我们可以把这个结构重构成抽象父类的模板方法（将在下一篇博客中，来进行实现）。
至此，我们已经写好了输入验证器，可以在客户端来使用了，但是UITextField不认识它们，所以我们需要自己的UITextField版本。我们要创建UITextField的子类，其中有一个InputValidator的引用，以及一个方法validate。代码如下：
CustomTextField.h中CustomTextField的类声明
#import<UIKit/UIKit.h> #import"InputValidator.h" @interfaceCustomTextField:UITextField @property(nonatomic,strong)InputValidator*inputValidator;//用一个属性保持对InputValidator的引用。 -(BOOL)validate; @end
CustomTextField有一个属性保持着对InputValidator的引用。当调用它的validate方法时，它会使用这个InputValidator引用，开始进行实际的验证过程。
CustomTextField.m中CustomTextField的实现
#import"CustomTextField.h"
@implementationCustomTextField
-(BOOL)validate{
NSError*error=nil;
BOOLvalidationResult=[_inputValidatorvalidateInput:selferror:&error];
if(!validationResult){
//通过这个例子也让自己明白了，NSError的具体用法。
UIAlertView*alertView=[[UIAlertViewalloc]initWithTitle:[errorlocalizedDescription]message:[errorlocalizedFailureReason]delegate:nilcancelButtonTitle:@"确定"otherButtonTitles:nil,nil];
[alertViewshow];
}
returnvalidationResult;
}
@end
validate方法向inputValidator引用发送了[_inputValidatorvalidateInput:selferror:&error]消息。CustomTextField无需知道使用的是什么类型的InputValidator以及算法的任何细节，这就是策略模式的好处。对于客户端使用来说，只需要调用validate方法就可以了。因此在将来如果添加了新的InputValidator,客户端不需要做任何的改动的。
下面，我们看下客户端是怎么使用的，代码如下。
#import"ViewController.h" #import"CustomTextField.h" #import"InputValidator.h" #import"NumberInputValidator.h" #import"AlphaInputValidator.h" @interfaceViewController()<UITextFieldDelegate> @property(weak,nonatomic)IBOutletCustomTextField*numberTF; @property(weak,nonatomic)IBOutletCustomTextField*alphaTF; @end
@implementationViewController
-(void)viewDidLoad{
[superviewDidLoad];
InputValidator*numberValidator=[[NumberInputValidatoralloc]init];
InputValidator*alphaValidator=[[AlphaInputValidatoralloc]init];
_numberTF.inputValidator=numberValidator;
_alphaTF.inputValidator=alphaValidator;
}
-(void)didReceiveMemoryWarning{
[superdidReceiveMemoryWarning];
//Disposeofanyresourcesthatcanberecreated.
}
#pragmamark-UITextFieldDelegate
-(void)textFieldDidEndEditing:(UITextField*)textField{
if([textFieldisKindOfClass:[CustomTextFieldclass]]){
[(CustomTextField*)textFieldvalidate];
}
}
@end
可以看出，我们不需要那些条件语句了，相反，我们使用一条简洁得多的语句，实现同样的数据验证。除了上面多了一条确保textField对象的类型是CustomField的额外检查之外，不应再有任何复杂的东西。
Strategy模式有下面的一些优点：
1)相关算法系列Strategy类层次为Context定义了一系列的可供重用的算法或行为。继承有助于析取出这些算法中的公共功能。
2)提供了可以替换继承关系的办法：继承提供了另一种支持多种算法或行为的方法。你可以直接生成一个Context类的子类，从而给它以不同的行为。但这会将行为硬行编制到Context中，而将算法的实现与Context的实现混合起来,从而使Context难以理解、难以维护和难以扩展，而且还不能动态地改变算法。最后你得到一堆相关的类,它们之间的唯一差别是它们所使用的算法或行为。将算法封装在独立的Strategy类中使得你可以独立于其Context改变它，使它易于切换、易于理解、易于扩展。
3)消除了一些ifelse条件语句：Strategy模式提供了用条件语句选择所需的行为以外的另一种选择。当不同的行为堆砌在一个类中时,很难避免使用条件语句来选择合适的行为。将行为封装在一个个独立的Strategy类中消除了这些条件语句。含有许多条件语句的代码通常意味着需要使用Strategy模式。
4)实现的选择Strategy模式可以提供相同行为的不同实现。客户可以根据不同时间/空间权衡取舍要求从不同策略中进行选择。
Strategy模式缺点:
1)客户端必须知道所有的策略类，并自行决定使用哪一个策略类:本模式有一个潜在的缺点，就是一个客户要选择一个合适的Strategy就必须知道这些Strategy到底有何不同。此时可能不得不向客户暴露具体的实现问题。因此仅当这些不同行为变体与客户相关的行为时,才需要使用Strategy模式。
2)Strategy和Context之间的通信开销：无论各个ConcreteStrategy实现的算法是简单还是复杂,它们都共享Strategy定义的接口。因此很可能某些ConcreteStrategy不会都用到所有通过这个接口传递给它们的信息；简单的ConcreteStrategy可能不使用其中的任何信息！这就意味着有时Context会创建和初始化一些永远不会用到的参数。如果存在这样问题,那么将需要在Strategy和Context之间更进行紧密的耦合。
3)策略模式将造成产生很多策略类：可以通过使用享元模式在一定程度上减少对象的数量。增加了对象的数目Strategy增加了一个应用中的对象的数目。有时你可以将Strategy实现为可供各Context共享的无状态的对象来减少这一开销。任何其余的状态都由Context维护。Context在每一次对Strategy对象的请求中都将这个状态传递过去。共享的Strategy不应在各次调用之间维护状态。