JS设计模式之惰性模式（二）

惰性模式：减少代码每次执行时的重复性判断，通过重新定义对象来避免原对象中的分支判断，提高网站性能。

例如针对不同浏览器的事件注册方法：

var AddEvent = function(dom, type, fn){
 if(dom.addEventListener){
 dom.addEventListener(type, fn, false);
 }else if(dom.attachEvent){
 dom.attachEvent('on'+type, fn);
 }else{
 dom['on'+type] = fn;
 }
}

从上面的方法可以发现，每次为元素绑定事件时，都会进行检测判断，这是多余的，因为在同一浏览器中分支判断结果是唯一的，不可能走不同的分支。

我们可以用惰性模式来解决这个问题，既然第一次调用该方法时已经判断过了，那么就可以在第一次执行时根据判断结果重新定义该方法。

惰性模式主要有两种实现方法：

加载即执行：JavaScript文件加载时通过闭包执行对方法进行重新定义，在页面加载时会消耗一定的资源。

var AddEvent = function(dom, type, fn){
 if(dom.addEventListener){
return function(dom, type, fn){
 dom.addEventListener(type, fn, false);
 }
 }else if(dom.attachEvent){
return function(dom, type, fn){
 dom.attachEvent('on'+type, fn);
 }
 }else{
return function(dom, type, fn){
 dom['on'+type] = fn;
 }
 }
}();

惰性执行：第一次执行函数时在函数内部对其进行显示重写，最后调用重写后的方法完成第一次方法调用。

var AddEvent = function(dom, type, fn){
 if(dom.addEventListener){
AddEvent = function(dom, type, fn){
 dom.addEventListener(type, fn, false);
 }
 }else if(dom.attachEvent){
AddEvent = function(dom, type, fn){
 dom.attachEvent('on'+type, fn);
 }
 }else{
AddEvent = function(dom, type, fn){
 dom['on'+type] = fn;
 }
 }
 AddEvent(dom, type, fn);
};

与加载即执行不同的是，JS文件加载完成后，惰性执行的函数还没有被重新定义，当函数被首次调用时才会被重定义。这两种惰性方式都避免了冗余的分支判断。

惰性模式的应用场景非常广泛，特别是当今浏览器种类繁多的现象，很多功能在不同浏览器中实现不一，为了兼容不同的浏览器，代码中往往会有许多对不同浏览器的分支判断，比如事件处理、XMLHttpRequest对象创建等，造成代码臃肿冗余，惰性模式正好可以解决这种问题，提高代码执行效率。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持我们。

赞 (0)

相关推荐

  • javascript 设计模式之单体模式 面向对象学习基础

    单体模式(singleton) 单体是在脚本加载时创建的,能将一系列有关联的变量和方法组织为一个逻辑单元,逻辑单元里面的内容通过单一的变量进行访问: 一个单体主要分为三部分 用于访问内部信息的入口变量(如:Sky) 属性(如:nickName/age/timeInfo) 方法(如:sayHello) 基本结构 复制代码 代码如下: var Sky = { /* * 作用一,变量管理 */ nickName: "sky", age: "26", /* * 作用二,加载

  • 小议javascript 设计模式 推荐

    记得早前就说过要和大家分享"javascript设计模式",迟迟没写不是因为我懒,最近确实太忙,忙工作,忙旅游(啊哦?),好不容易这几天空闲了,接下来是兑现之前空口白话的时间了. 在讨论设计模式之前,请确认您已经有一定的脚本编程基础,如果不甚了解,建议可以先查阅本人很久之前写的这篇<浅谈javascript面向对象编程>请看下一篇文章. 讲到设计模式,不得不先重点着墨于"接口设计",因为接口设计在设计模式中的意义太大了,大于模式本身.直观起见,先介绍一下

  • JavaScript 设计模式 安全沙箱模式

    命名空间 JavaScript本身中没有提供命名空间机制,所以为了避免不同函数.对象以及变量名对全局空间的污染,通常的做法是为你的应用程序或者库创建一个唯一的全局对象,然后将所有方法与属性添加到这个对象上. 复制代码 代码如下: /* BEFORE: 5 globals */ // constructors function Parent() {} function Child() {} // a variable var some_var = 1; // some objects var mo

  • JavaScript 设计模式之组合模式解析

    怎么说呢?!就像是动物(组合对象)一样,当它生下后代(叶对象)时,它的后代就有了某种功能(比如:挖洞,听力好等等):也像是一棵树,它有一个根(组合对象)然后是从这个棵树向外冒出的其他枝杆(组合对象)以及从这些枝杆又向外长的叶子(叶对象).换句话说,就是当祖先已经有了,那么只要从这个祖先衍生出来的其他孩子(包括这个祖先下的其他组合对象)已经就具备了某种功能,看上去貌似又有些像是继承."组合模式"在组合对象的层次体系中有两种类型的对象:叶对象和组合对象.组合模式擅长于对大批对象进行操作.

  • js如何实现设计模式中的模板方法

    在js中如何实现设计模式中的模板方法? 思路的产生必然要求熟悉js,如何实现?就很简单了,都知道在js中如果定义两个相同名称的方法,前一个方法就会被后一个方法覆盖掉,使用此特点就可以实现模板方法. 例如在实际的项目中有很多页面操作的步骤基本相同,但局部细节却不一样.例如在我所在的项目中,就有很多展示数据库记录的页面,每个页面都存在读取记录,查询记录,增加删除,修改记录等相同的操作,但对应的后台方法却不一样. 复制代码 代码如下: function ListCommon2() { var urlA

  • javascript设计模式之解释器模式详解

    javascript设计模式之解释器模式详解

    神马是"解释器模式"? 先翻开<GOF>看看Definition:给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子. 在开篇之前还是要科普几个概念: 抽象语法树: 解释器模式并未解释如何创建一个抽象语法树.它不涉及语法分析.抽象语法树可用一个表驱动的语法分析程序来完成,也可用手写的(通常为递归下降法)语法分析程序创建,或直接client提供. 解析器: 指的是把描述客户端调用要求的表达式,经过解析,形成一个抽象语法树的程序. 解

  • JavaScript设计模式之观察者模式（发布者-订阅者模式）

    观察者模式( 又叫发布者-订阅者模式 )应该是最常用的模式之一. 在很多语言里都得到大量应用. 包括我们平时接触的dom事件. 也是js和dom之间实现的一种观察者模式. 复制代码 代码如下: div.onclick  =  function click (){ alert ( "click' ) } 只要订阅了div的click事件. 当点击div的时候, function click就会被触发. 那么到底什么是观察者模式呢. 先看看生活中的观察者模式. 好莱坞有句名言. "不要给我

  • JavaScript设计模式之原型模式(Object.create与prototype)介绍

    原型模式说明 说明:使用原型实例来 拷贝 创建新的可定制的对象:新建的对象,不需要知道原对象创建的具体过程: 过程:Prototype => new ProtoExam => clone to new Object; 使用相关代码: 复制代码 代码如下: function Prototype() {     this.name = '';     this.age = '';     this.sex = ''; } Prototype.prototype.userInfo = functio

  • javascript设计模式 接口介绍

    这本书中第一个重要的内容就是接口. 大家对接口应该都不陌生,简单的说接口就是一个契约或者规范.在强类型的面相对象语言中,接口可以很容易的实现.但是在javascript中并没有原生的创建或者实现接口的方式,或者判定一个类型是否实现了某个接口,我们只能利用js的灵活性的特点,模拟接口. 在javascript中实现接口有三种方式:注释描述.属性验证.鸭子模型. note:因为我看的是英文书,翻译水平有限,不知道有些词汇如何翻译,大家只能领会精神了. 1. 注释描述 (Describing Inte

  • 常用的Javascript设计模式小结

    常用的Javascript设计模式小结

    <Practical Common Lisp>的作者 Peter Seibel 曾说,如果你需要一种模式,那一定是哪里出了问题.他所说的问题是指因为语言的天生缺陷,不得不去寻求和总结一种通用的解决方案. 不管是弱类型或强类型,静态或动态语言,命令式或说明式语言.每种语言都有天生的优缺点.一个牙买加运动员, 在短跑甚至拳击方面有一些优势,在练瑜伽上就欠缺一些. 术士和暗影牧师很容易成为一个出色的辅助,而一个背着梅肯满地图飞的敌法就会略显尴尬. 换到程序中, 静态语言里可能需要花很多功夫来实现装饰

随机推荐