深入理解JavaScript系列(33):设计模式之策略模式(转)

介绍

策略模式定义了算法家族,分别封装起来,让他们之间可以互相替换,此模式让算法的变化不会影响到使用算法的客户。

正文

在理解策略模式之前,我们先来一个例子,一般情况下,如果我们要做数据合法性验证,很多时候都是按照swith语句来判断,但是这就带来几个问题,首先如果增加需求的话,我们还要再次修改这段代码以增加逻辑,而且在进行单元测试的时候也会越来越复杂,代码如下:

        validator = {             validate: function (value, type) {                 switch (type) {                     case 'isNonEmpty ':                         {                             return true; // NonEmpty 验证结果                         }                     case 'isNumber ':                         {                             return true; // Number 验证结果                             break;                         }                     case 'isAlphaNum ':                         {                             return true; // AlphaNum 验证结果                         }                     default:                         {                             return true;                         }                 }             }         };         //  测试         alert(validator.validate("123", "isNonEmpty"));

那如何来避免上述代码中的问题呢,根据策略模式,我们可以将相同的工作代码单独封装成不同的类,然后通过统一的策略处理类来处理,OK,我们先来定义策略处理类,代码如下:

var validator = {// 所有可以的验证规则处理类存放的地方,后面会单独定义     types: {},// 验证类型所对应的错误消息     messages: [],// 当然需要使用的验证类型     config: {},// 暴露的公开验证方法     // 传入的参数是 key => value对     validate: function (data) {var i, msg, type, checker, result_ok;// 清空所有的错误信息         this.messages = [];for (i in data) {             if (data.hasOwnProperty(i)) {                type = this.config[i];  // 根据key查询是否有存在的验证规则                 checker = this.types[type]; // 获取验证规则的验证类                  if (!type) {                     continue; // 如果验证规则不存在,则不处理                 }                 if (!checker) { // 如果验证规则类不存在,抛出异常                     throw {                         name: "ValidationError",                         message: "No handler to validate type " + type                     };                 }                result_ok = checker.validate(data[i]); // 使用查到到的单个验证类进行验证                 if (!result_ok) {                     msg = "Invalid value for *" + i + "*, " + checker.instructions;                     this.messages.push(msg);                 }             }         }         return this.hasErrors();     },// helper     hasErrors: function () {         return this.messages.length !== 0;     } };

然后剩下的工作,就是定义types里存放的各种验证类了,我们这里只举几个例子:

// 验证给定的值是否不为空 validator.types.isNonEmpty = {     validate: function (value) {         return value !== "";     },     instructions: "传入的值不能为空" };// 验证给定的值是否是数字 validator.types.isNumber = {     validate: function (value) {         return !isNaN(value);     },     instructions: "传入的值只能是合法的数字,例如:1, 3.14 or 2010" };// 验证给定的值是否只是字母或数字 validator.types.isAlphaNum = {     validate: function (value) {         return !/[^a-z0-9]/i.test(value);     },     instructions: "传入的值只能保护字母和数字,不能包含特殊字符" };

使用的时候,我们首先要定义需要验证的数据集合,然后还需要定义每种数据需要验证的规则类型,代码如下:

var data = {     first_name: "Tom",     last_name: "Xu",     age: "unknown",     username: "TomXu" };validator.config = {     first_name: 'isNonEmpty',     age: 'isNumber',     username: 'isAlphaNum' };

最后,获取验证结果的代码就简单了:

validator.validate(data);if (validator.hasErrors()) {     console.log(validator.messages.join("\n")); }

总结

策略模式定义了一系列算法,从概念上来说,所有的这些算法都是做相同的事情,只是实现不同,他可以以相同的方式调用所有的方法,减少了各种算法类与使用算法类之间的耦合。

从另外一个层面上来说,单独定义算法类,也方便了单元测试,因为可以通过自己的算法进行单独测试。

实践中,不仅可以封装算法,也可以用来封装几乎任何类型的规则,是要在分析过程中需要在不同时间应用不同的业务规则,就可以考虑是要策略模式来处理各种变化。

同步与推荐

本文已同步至目录索引:深入理解JavaScript系列

 

http://www.cnblogs.com/TomXu/archive/2012/03/05/2358552.html

时间: 2024-12-03 04:44:28

深入理解JavaScript系列(33):设计模式之策略模式(转)的相关文章

深入理解JavaScript系列(3) 全面解析Module模式_javascript技巧

简介 Module模式是JavaScript编程中一个非常通用的模式,一般情况下,大家都知道基本用法,本文尝试着给大家更多该模式的高级使用方式. 首先我们来看看Module模式的基本特征: 模块化,可重用 封装了变量和function,和全局的namaspace不接触,松耦合 只暴露可用public的方法,其它私有方法全部隐藏 关于Module模式,最早是由YUI的成员Eric Miraglia在4年前提出了这个概念,我们将从一个简单的例子来解释一下基本的用法(如果你已经非常熟悉了,请忽略这一节

深入理解JavaScript系列(33):设计模式之策略模式详解

 这篇文章主要介绍了深入理解JavaScript系列(33):设计模式之策略模式详解,策略模式定义了算法家族,分别封装起来,让他们之间可以互相替换,此模式让算法的变化不会影响到使用算法的客户,需要的朋友可以参考下     介绍 策略模式定义了算法家族,分别封装起来,让他们之间可以互相替换,此模式让算法的变化不会影响到使用算法的客户. 正文 在理解策略模式之前,我们先来一个例子,一般情况下,如果我们要做数据合法性验证,很多时候都是按照swith语句来判断,但是这就带来几个问题,首先如果增加需求的话

深入理解JavaScript系列(19):求值策略(Evaluation strategy)详解

 这篇文章主要介绍了深入理解JavaScript系列(19):求值策略(Evaluation strategy)详解,本文讲解了一般理论.按值传递.按引用传递.按共享传递(Call by sharing).按共享传递是按值传递的特例等内容,需要的朋友可以参考下     介绍 本章,我们将讲解在ECMAScript向函数function传递参数的策略. 计算机科学里对这种策略一般称为"evaluation strategy"(大叔注:有的人说翻译成求值策略,有的人翻译成赋值策略,通看下面

深入理解JavaScript系列(25):设计模式之单例模式详解

 这篇文章主要介绍了深入理解JavaScript系列(25):设计模式之单例模式详解,本文给出了多种单例模式的实现方式,需要的朋友可以参考下     介绍 从本章开始,我们会逐步介绍在JavaScript里使用的各种设计模式实现,在这里我不会过多地介绍模式本身的理论,而只会关注实现.OK,正式开始. 在传统开发工程师眼里,单例就是保证一个类只有一个实例,实现的方法一般是先判断实例存在与否,如果存在直接返回,如果不存在就创建了再返回,这就确保了一个类只有一个实例对象.在JavaScript里,单例

深入理解JavaScript系列(26):设计模式之构造函数模式详解

 这篇文章主要介绍了深入理解JavaScript系列(26):设计模式之构造函数模式详解,本文讲解了基本用法.构造函数与原型.只能用new吗?.强制使用new.原始包装函数等内容,需要的朋友可以参考下     介绍 构造函数大家都很熟悉了,不过如果你是新手,还是有必要来了解一下什么叫构造函数的.构造函数用于创建特定类型的对象--不仅声明了使用的对象,构造函数还可以接受参数以便第一次创建对象的时候设置对象的成员值.你可以自定义自己的构造函数,然后在里面声明自定义类型对象的属性或方法. 基本用法 在

深入理解JavaScript系列(27):设计模式之建造者模式详解

 这篇文章主要介绍了深入理解JavaScript系列(27):设计模式之建造者模式详解,建造者模式可以将一个复杂对象的构建与其表示相分离,使得同样的构建过程可以创建不同的表示,需要的朋友可以参考下     介绍 在软件系统中,有时候面临着"一个复杂对象"的创建工作,其通常由各个部分的子对象用一定的算法构成:由于需求的变化,这个复杂对象的各个部分经常面临着剧烈的变化,但是将它们组合在一起的算法确相对稳定.如何应对这种变化?如何提供一种"封装机制"来隔离出"复

深入理解JavaScript系列(28):设计模式之工厂模式详解

 这篇文章主要介绍了深入理解JavaScript系列(28):设计模式之工厂模式详解,工厂模式定义一个用于创建对象的接口,这个接口由子类决定实例化哪一个类,需要的朋友可以参考下     介绍 与创建型模式类似,工厂模式创建对象(视为工厂里的产品)时无需指定创建对象的具体类. 工厂模式定义一个用于创建对象的接口,这个接口由子类决定实例化哪一个类.该模式使一个类的实例化延迟到了子类.而子类可以重写接口方法以便创建的时候指定自己的对象类型. 这个模式十分有用,尤其是创建对象的流程赋值的时候,比如依赖于

深入理解JavaScript系列(29):设计模式之装饰者模式详解

 这篇文章主要介绍了深入理解JavaScript系列(29):设计模式之装饰者模式详解,装饰者用用于包装同接口的对象,不仅允许你向方法添加行为,而且还可以将方法设置成原始对象调用(例如装饰者的构造函数),需要的朋友可以参考下     介绍 装饰者提供比继承更有弹性的替代方案. 装饰者用用于包装同接口的对象,不仅允许你向方法添加行为,而且还可以将方法设置成原始对象调用(例如装饰者的构造函数). 装饰者用于通过重载方法的形式添加新功能,该模式可以在被装饰者前面或者后面加上自己的行为以达到特定的目的.

深入理解JavaScript系列(30):设计模式之外观模式详解

 这篇文章主要介绍了深入理解JavaScript系列(30):设计模式之外观模式详解,外观模式(Facade)为子系统中的一组接口提供了一个一致的界面,此模块定义了一个高层接口,这个接口值得这一子系统更加容易使用,需要的朋友可以参考下     介绍 外观模式(Facade)为子系统中的一组接口提供了一个一致的界面,此模块定义了一个高层接口,这个接口值得这一子系统更加容易使用. 正文 外观模式不仅简化类中的接口,而且对接口与调用者也进行了解耦.外观模式经常被认为开发者必备,它可以将一些复杂操作封装