欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  移动技术

iOS应用运用设计模式中的Strategy策略模式的开发实例

程序员文章站 2023-12-04 21:07:16
  在写程序的时候,我们经常会碰到这样的场景:把一堆算法塞到同一段代码中,然后使用if-else或switch-case条件语句来决定要使用哪个算法?这些算法可能...

  在写程序的时候,我们经常会碰到这样的场景:把一堆算法塞到同一段代码中,然后使用if-else或switch-case条件语句来决定要使用哪个算法?这些算法可能是一堆相似的类函数或方法,用以解决相关的问题。比如,一个验证输入数据的例程,数据本身可以是任何数据类型(如nsstring、cgfloat等),每种数据类型需要不同的验证算法。如果能把每个算法封装成一个对象,那么就能消除根据数据类型决定使用什么算法的一堆if-else或switch-case语句。


    我们把相关算法分离为不同的类,称为策略模式。策略模式:定义一系列算法,把它们一个个封装起来,并且使它们可相互替换。本模式使得算法可独立于使用它的客户端而变化。

    在以下情形下,我们应该考虑使用策略模式。
    @:一个类在其操作中,使用多个条件语句来定义许多行为,我们可以把相关的条件分支移到它们自己的策略类中。
    @:需要算法的各种变体。
    @:需要避免把复杂的、与算法相关的数据结构暴漏给客户端。

    我们用一个简单的例子来说明以下,策略模式是怎么使用的。假设有两个uitextfield,一个uitextfield只能输入字母,另一个uitextfield只能输入数字,为了确保输入的有效性,我们需要在用户结束文本框的编辑时做下验证。我们把数据验证放在代理方法textfielddidendedting中。

    如果不使用策略模式,我们的代码会写成这样:

复制代码 代码如下:

- (void)textfielddidendediting:(uitextfield *)textfield {
    if (textfield == self.numbertf) {
        // 验证其值只包含数字
       
    }else if (textfield == self.alphatf) {
        // 验证其值只包含字母
       
    }
}

    要是有更多不同类型的文本框,条件语句还会继续下去。如果能去掉这些条件语句,代码会更容易管理,将来对代码的维护也会容易许多。

    现在的目标是把这些验证检查提到各种策略类中,这样他们就能在代理方法和其他方法之中重用。每个验证都从文本框取出输入值,然后根据所h需的策略进行验证,最后返回一个bool值。如果返回失败,还会返回一个nserror实例。返回的nserror可以解释失败的原因。

    我们设计一个抽象基类inputvalidator,里面有一个validateinput:input error:error方法。分别有两个子类numberinputvalidator、alphainputvalidator。具体的代码如下所示:

    inputvalidator.h中抽象inputvalidator的类声明

复制代码 代码如下:

static nsstring *const inputvalidationerrordomain = @"inputvalidationerrordomain";
 
@interface inputvalidator : nsobject
/**
 *  实际验证策略的存根方法
 */
- (bool)validateinput:(uitextfield *)input error:(nserror *__autoreleasing *)error;
 
@end

    这个方法还有一个nserror指针的引用,当有错误发生时(即验证失败),方法会构造一个nserror实例,并赋值给这个指针,这样使用验证的地方就能做详细的错误处理。

    inputvalidator.m中抽象inputvalidator的默认实现

#import "inputvalidator.h"
 

复制代码 代码如下:

@implementation inputvalidator
 
- (bool)validateinput:(uitextfield *)input error:(nserror *__autoreleasing *)error {
    if (error) {
        *error = nil;
    }
    return no;
}
 
@end

    我们已经定义了输入验证器的行为,然后我们要编写真正的输入验证器了,先来写数值型的,如下:

    numberinputvalidator.h中numberinputvalidator的类定义

复制代码 代码如下:

#import "inputvalidator.h"
 
@interface numberinputvalidator : inputvalidator
 
/**
 *  这里重新声明了这个方法,以强调这个子类实现或重载了什么,这不是必须的,但是是个好习惯。
 */
- (bool)validateinput:(uitextfield *)input error:(nserror *__autoreleasing *)error;
@end

    numberinputvalidator.m中numberinputvalidator的实现
复制代码 代码如下:

#import "numberinputvalidator.h"
 
@implementation numberinputvalidator
 
- (bool)validateinput:(uitextfield *)input error:(nserror *__autoreleasing *)error {
    nserror *regerror = nil;
    nsregularexpression *regex = [nsregularexpression regularexpressionwithpattern:@"^[0-9]*$" 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对象是存在的
            nsstring *description = nslocalizedstring(@"验证失败", @"");
            nsstring *reason = nslocalizedstring(@"输入仅能包含数字", @"");
            nsarray *objarray = [nsarray arraywithobjects:description, reason, nil];
            nsarray *keyarray = [nsarray arraywithobjects:nslocalizeddescriptionkey, nslocalizedfailurereasonerrorkey, nil];
            
            nsdictionary *userinfo = [nsdictionary dictionarywithobjects:objarray forkeys:keyarray];
            //错误被关联到定制的错误代码1001和在inputvalidator的头文件中。
            *error = [nserror errorwithdomain:inputvalidationerrordomain code:1001 userinfo:userinfo];
        }
        
        return no;
    }
    
    return yes;
}
 
@end

    现在,我们来编写字母验证的实现,代码如下:

    alphainputvalidator.h中alphainputvalidator的类定义

复制代码 代码如下:

#import "inputvalidator.h"
@interface alphainputvalidator : inputvalidator
 
- (bool)validateinput:(uitextfield *)input error:(nserror *__autoreleasing *)error;
 
@end

    alphainputvalidator.m中alphainputvalidator的实现:

#import "alphainputvalidator.h"
 

复制代码 代码如下:

@implementation alphainputvalidator
 
- (bool)validateinput:(uitextfield *)input error:(nserror *__autoreleasing *)error {
    nserror *regerror = nil;
    nsregularexpression *regex = [nsregularexpression regularexpressionwithpattern:@"^[a-za-z]*$" 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对象是存在的
            nsstring *description = nslocalizedstring(@"验证失败", @"");
            nsstring *reason = nslocalizedstring(@"输入仅能包字母", @"");
            nsarray *objarray = [nsarray arraywithobjects:description, reason, nil];
            nsarray *keyarray = [nsarray arraywithobjects:nslocalizeddescriptionkey, nslocalizedfailurereasonerrorkey, nil];
            
            nsdictionary *userinfo = [nsdictionary dictionarywithobjects:objarray forkeys:keyarray];
            *error = [nserror errorwithdomain:inputvalidationerrordomain code:1002 userinfo:userinfo]; //错误被关联到定制的错误代码1002和在inputvalidator的头文件中。
        }
        
        return no;
    }
    
    return yes;
}
 
@end

    alphainputvalidator也是实现了validateinput方法的inputvalidator类型。它的代码结构和算法跟numberinputvalidator相似,只是使用了不同的正则表达式,不同错误代码和消息。可以看到两个版本的代码有很多重复。两个算法结构相同,我们可以把这个结构,我们可以把这个结构重构成抽象父类的模板方法(将在下一篇博客中,来进行实现)。

    至此,我们已经写好了输入验证器,可以在客户端来使用了,但是uitextfield不认识它们,所以我们需要自己的uitextfield版本。我们要创建uitextfield的子类,其中有一个inputvalidator的引用,以及一个方法validate。代码如下:

customtextfield.h中customtextfield的类声明

复制代码 代码如下:

#import <uikit/uikit.h>
#import "inputvalidator.h"
@interface customtextfield : uitextfield
 
@property (nonatomic, strong) inputvalidator *inputvalidator; //用一个属性保持对inputvalidator的引用。
 
- (bool)validate;
 
@end

    customtextfield有一个属性保持着对inputvalidator的引用。当调用它的validate方法时,它会使用这个inputvalidator引用,开始进行实际的验证过程。

    customtextfield.m中customtextfield的实现

复制代码 代码如下:

#import "customtextfield.h"
 
@implementation customtextfield
 
- (bool)validate {
    nserror *error = nil;
    bool validationresult = [_inputvalidator validateinput:self error:&error];
    
    if (!validationresult) {
        // 通过这个例子也让自己明白了,nserror的具体用法。
        uialertview *alertview = [[uialertview alloc]initwithtitle:[error localizeddescription] message:[error localizedfailurereason] delegate:nil cancelbuttontitle:@"确定" otherbuttontitles:nil, nil];
        [alertview show];
    }
    
    return validationresult;
}
 
@end

    validate方法向inputvalidator引用发送了[_inputvalidator validateinput:self error:&error]消息。customtextfield无需知道使用的是什么类型的inputvalidator以及算法的任何细节,这就是策略模式的好处。对于客户端使用来说,只需要调用validate方法就可以了。因此在将来如果添加了新的inputvalidator,客户端不需要做任何的改动的。

    下面,我们看下客户端是怎么使用的,代码如下。

复制代码 代码如下:

#import "viewcontroller.h"
#import "customtextfield.h"
#import "inputvalidator.h"
#import "numberinputvalidator.h"
#import "alphainputvalidator.h"
@interface viewcontroller () <uitextfielddelegate>
 
@property (weak, nonatomic) iboutlet customtextfield *numbertf;
@property (weak, nonatomic) iboutlet customtextfield *alphatf;
 
 
@end
 

@implementation viewcontroller
 
复制代码 代码如下:

- (void)viewdidload {
    [super viewdidload];
    
    inputvalidator *numbervalidator = [[numberinputvalidator alloc] init];
    inputvalidator *alphavalidator = [[alphainputvalidator alloc] init];
    
    _numbertf.inputvalidator = numbervalidator;
    _alphatf.inputvalidator = alphavalidator;
}
 
- (void)didreceivememorywarning {
    [super didreceivememorywarning];
    // dispose of any resources that can be recreated.
}
 
#pragma mark - uitextfielddelegate
 
- (void)textfielddidendediting:(uitextfield *)textfield {
    if ([textfield iskindofclass:[customtextfield class]]) {
        [(customtextfield *)textfield validate];
    }
}
 
@end

    可以看出,我们不需要那些条件语句了,相反,我们使用一条简洁得多的语句,实现同样的数据验证。除了上面多了一条确保textfield对象的类型是customfield的额外检查之外,不应再有任何复杂的东西。

strategy模式有下面的一些优点:
1) 相关算法系列 strategy类层次为context定义了一系列的可供重用的算法或行为。 继承有助于析取出这些算法中的公共功能。
2) 提供了可以替换继承关系的办法: 继承提供了另一种支持多种算法或行为的方法。你可以直接生成一个context类的子类,从而给它以不同的行为。但这会将行为硬行编制到 context中,而将算法的实现与context的实现混合起来,从而使context难以理解、难以维护和难以扩展,而且还不能动态地改变算法。最后你得到一堆相关的类 , 它们之间的唯一差别是它们所使用的算法或行为。 将算法封装在独立的strategy类中使得你可以独立于其context改变它,使它易于切换、易于理解、易于扩展。
3) 消除了一些if else条件语句 :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不应在各次调用之间维护状态。