深入理解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-09-29 08:07:35

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

前端也要学系列:设计模式之策略模式

做前端开发已经好几年了,对设计模式一直没有深入学习总结过.随着架构相关的工作越来越多,越来越能感觉到设计模式成为了我前进道路上的一个阻碍.所以从今天开始深入学习和总结经典的设计模式以及面向对象的几大原则. 今天第一天,首先来讲策略模式. 什么是策略模式? GoF四兄弟的经典<设计模式>中,对策略模式的定义如下: 定义一系列的算法,把它们一个个封装起来,并且使它们可互相替换. 上边这句话,从字面来看很简单.但是如何在开发过程中去应用,仅凭一个定义依然是一头雾水.以笔者曾经做过的商户进销存系统为例

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

介绍 策略模式定义了算法家族,分别封装起来,让他们之间可以互相替换,此模式让算法的变化不会影响到使用算法的客户. 正文 在理解策略模式之前,我们先来一个例子,一般情况下,如果我们要做数据合法性验证,很多时候都是按照swith语句来判断,但是这就带来几个问题,首先如果增加需求的话,我们还要再次修改这段代码以增加逻辑,而且在进行单元测试的时候也会越来越复杂,代码如下: validator = { validate: function (value, type) { switch (type) { c

深入理解JavaScript系列(41):设计模式之模板方法

介绍 模板方法(TemplateMethod)定义了一个操作中的算法的骨架,而将一些步骤延迟到子类中.模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤. 模板方法是一种代码复用的基本技术,在类库中尤为重要,因为他们提取了类库中的公共行为.模板方法导致一种反向的控制结构,这种结构就是传说中的“好莱坞法则”,即“别找找我们,我们找你”,这指的是父类调用一个类的操作,而不是相反.具体体现是面向对象编程编程语言里的抽象类(以及其中的抽象方法),以及继承该抽象类(和抽象方法)的子类.

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

介绍 本章,我们将讲解在ECMAScript向函数function传递参数的策略. 计算机科学里对这种策略一般称为“evaluation strategy”(大叔注:有的人说翻译成求值策略,有的人翻译成赋值策略,通看下面的内容,我觉得称为赋值策略更为恰当,anyway,标题还是写成大家容易理解的求值策略吧),例如在编程语言为求值或者计算表达式设置规则.向函数传递参数的策略是一个特殊的case. http://dmitrysoshnikov.com/ecmascript/chapter-8-eva

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

介绍 从本章开始,我们会逐步介绍在JavaScript里使用的各种设计模式实现,在这里我不会过多地介绍模式本身的理论,而只会关注实现.OK,正式开始. 在传统开发工程师眼里,单例就是保证一个类只有一个实例,实现的方法一般是先判断实例存在与否,如果存在直接返回,如果不存在就创建了再返回,这就确保了一个类只有一个实例对象.在JavaScript里,单例作为一个命名空间提供者,从全局命名空间里提供一个唯一的访问点来访问该对象. 正文 在JavaScript里,实现单例的方式有很多种,其中最简单的一个方

深入理解JavaScript系列(31):设计模式之代理模式

介绍 代理,顾名思义就是帮助别人做事,GoF对代理模式的定义如下: 代理模式(Proxy),为其他对象提供一种代理以控制对这个对象的访问. 代理模式使得代理对象控制具体对象的引用.代理几乎可以是任何对象:文件,资源,内存中的对象,或者是一些难以复制的东西. 正文 我们来举一个简单的例子,假如dudu要送酸奶小妹玫瑰花,却不知道她的联系方式或者不好意思,想委托大叔去送这些玫瑰,那大叔就是个代理(其实挺好的,可以扣几朵给媳妇),那我们如何来做呢? // 先声明美女对象 var girl = func

深入理解JavaScript系列(36):设计模式之中介者模式

介绍 中介者模式(Mediator),用一个中介对象来封装一系列的对象交互.中介者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互. 主要内容来自:http://www.addyosmani.com/resources/essentialjsdesignpatterns/book/#mediatorpatternjavascript 正文 软件开发中,中介者是一个行为设计模式,通过提供一个统一的接口让系统的不同部分进行通信.一般,如果系统有很多子模块需要直接沟通,

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

介绍 外观模式(Facade)为子系统中的一组接口提供了一个一致的界面,此模块定义了一个高层接口,这个接口值得这一子系统更加容易使用. 正文 外观模式不仅简化类中的接口,而且对接口与调用者也进行了解耦.外观模式经常被认为开发者必备,它可以将一些复杂操作封装起来,并创建一个简单的接口用于调用. 外观模式经常被用于JavaScript类库里,通过它封装一些接口用于兼容多浏览器,外观模式可以让我们间接调用子系统,从而避免因直接访问子系统而产生不必要的错误. 外观模式的优势是易于使用,而且本身也比较轻量

深入理解JavaScript系列(38):设计模式之职责链模式

介绍 职责链模式(Chain of responsibility)是使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系.将这个对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理他为止. 也就是说,请求以后,从第一个对象开始,链中收到请求的对象要么亲自处理它,要么转发给链中的下一个候选者.提交请求的对象并不明确知道哪一个对象将会处理它——也就是该请求有一个隐式的接受者(implicit receiver).根据运行时刻,任一候选者都可以响应相应的请求,候选者的数目是任意