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

  在写程序的时候，我们经常会碰到这样的场景：把一堆算法塞到同一段代码中，然后使用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不应在各次调用之间维护状态。

时间： 2024-10-31 10:13:00

iOS应用运用设计模式中的Strategy策略模式的开发实例_IOS的相关文章

C++编程中使用设计模式中的policy策略模式的实例讲解_C 语言

   在看<C++设计新思维>的时候,发现在一开始就大篇幅的介绍策略模式(policy),策略模式不属于经典设计模式中的一种,但是其实在我们日常的开发中是必不可少的.policy,策略,方针,这里的意思是指把复杂功能的类尽量的拆分为功能单一的简单类的组合,简单的类只负责单纯行为或结构的某一方面.增加程序库的弹性,可复用性,可扩展性.policy是一个虚拟的概念,他定义了某一类class的一些接口规范,并不与C++语法的关键字对应,只是一个抽象的概念. 实例1: //policy模式的常见使用实

Java设计模式之Strategy(策略)模式

Strategy是属于设计模式中 对象行为型模式,主要是定义一系列的算法,把这些算法一个个封装成单独的类. Stratrgy应用比较广泛,比如,公司经营业务变化图,可能有两种实现方式,一个是线条曲线,一个是框图(bar),这是两种算法,可以使用Strategy实现. 这里以字符串替代为例, 有一个文件,我们需要读取后,希望替代其中相应的变量,然后输出.关于替代其中变量的方法可能有多种方法,这取决于用户的要求,所以我们要准备几套变量字符替代方案. 首先,我们建立一个抽象类RepTempRule 定

设计模式系列之六：策略模式

前言 策略模式是设计模式中的行为型模式,所谓行为型就是其主要使用在方法有很大灵活性的情况.而之前的工厂模式主要是对创建对象的优化,减少程序中使用new对象的次数.策略模式在Java源码中也是很常见的,比如我们要比较两个对象的大小,既可以使用默认的Comparable接口,也可以实现自定义的比较规则,即实现Comparator接口.这两种比较比较方法都是不同比较规则的体现,属于不同的策略.策略模式从定义上是这么说的:定义了算法家族,把这些不同的算法封装起来,让他们之间可以相互替换.从而使得算法的替

实例解析Ruby设计模式编程中Strategy策略模式的使用_ruby专题

今天你的leader兴致冲冲地找到你,希望你可以帮他一个小忙,他现在急着要去开会.要帮什么忙呢?你很好奇. 他对你说,当前你们项目的数据库中有一张用户信息表,里面存放了很用户的数据,现在需要完成一个选择性查询用户信息的功能.他说会传递给你一个包含许多用户名的数组,你需要根据这些用户名把他们相应的数据都给查出来. 这个功能很简单的嘛,你爽快地答应了.由于你们项目使用的是MySQL数据库,你很快地写出了如下代码: require 'mysql' class QueryUtil def find_us

iOS App设计模式开发中策略模式的实现示例_IOS

这次介绍一下策略模式(Strategy Pattern),相比之下是一种比较简单的模式.它也叫政策模式(Policy Pattern). 策略模式使用的就是面向对象的继承和多态机制,其他的没有什么玄机.策略模式适合使用在: 1. 多个类只有在算法或行为上稍有不同的场景. 2. 算法需要自由切换的场景. 3. 需要屏蔽算法规则的场景. 使用策略模式当然也有需要注意的地方,那么就是策略类不要太多,如果一个策略家族的具体策略数量超过4个,则需要考虑混合模式,解决策略类膨胀和对外暴露问题.在实际项目中,

php设计模式 Strategy(策略模式)

复制代码 代码如下: <?php /** * 策略模式(Strategy.php) * * 定义一系列算法,把它们一个个封装起来,并且使它们可相互替换,使用得算法的变化可独立于使用它的客户 * */ // ---以下是一系列算法的封闭---- interface CacheTable { public function get($key); public function set($key,$value); public function del($key); } // 不使用缓存 class

php设计模式 Strategy(策略模式)_php技巧

复制代码 代码如下: <?php /** * 策略模式(Strategy.php) * * 定义一系列算法,把它们一个个封装起来,并且使它们可相互替换,使用得算法的变化可独立于使用它的客户 * */ // ---以下是一系列算法的封闭---- interface CacheTable { public function get($key); public function set($key,$value); public function del($key); } // 不使用缓存 class

传统设计模式（一）策略模式

虫子以前在一家电商公司 会员的模块在这里分类很明确 不同的会员所具有的权限和行为不同,大多程序员会使用标准的oo技术,设计一个会员超类SuperUser,并让各种商家会员继承此超类 到这里无可厚非,但是在下面个过程中你可以就慢慢体会策略模式与你在代码里不停写逻辑判断所带来的区别有多大 所有的会员都具有下列行为 购物,评价,发布商品 public abstract class SuperUser { public SuperUser() { } public void shopping() { C

简单了解设计模式中的装饰者模式及C++版代码实现_C 语言

由遇到的问题引出的装饰模式 在 OO 设计和开发过程,可能会经常遇到以下的情况:我们需要为一个已经定义好的类添加新的职责(操作),通常的情况我们会给定义一个新类继承自定义好的类,这样会带来一个问题(将在本模式的讨论中给出).通过继承的方式解决这样的情况还带来了系统的复杂性,因为继承的深度会变得很深. 而装饰提供了一种给类增加职责的方法,不是通过继承实现的,而是通过组合. 有关这些内容在讨论中进一步阐述.模式选择装饰模式典型的结构图为: 在 结 构 图 中 , ConcreteComponent