JavaScript版装饰者模式
本文是基于JavaScript的装饰者模式
由浅入深介绍JavaScript的装饰者模式,以及与传统面向对象语言的装饰者模式的区别。
包含大量代码示例以及注释
内容包括
- 为什么需要装饰者模式
- 传统面向对象的装饰者模式
- JavaScript的装饰者
- 装饰函数
- 用AOP装饰函数
- AOP的应用实例
- 装饰者模式和代理模式的区别
为什么需要装饰者模式?
需要给对象动态添加职责
- 天冷添衣
- 需要飞行就加一双翅膀
- …
即需要对对象进行拓展,传统的方式存在的缺点
- 用继承的方式对对象进行拓展
- 这样会有较高的耦合性:当父类改变时,子类也跟着改变
- 继承也称为”白箱复用”,即父类中的细节在子类中是可见的,破坏了封装性
- 子类数量的爆炸
- 例如,4辆自行车需要4个类,每辆自行车都需要前灯、后灯、铃铛,则创建子类的数量为4*3=12
- 而如果是动态添加到自行车上只需要3个类
传统面向对象的装饰者模式
JS作为一门解释性语言,要给对象动态添加属性非常容易。
- 虽然改动了对象本身,与传统面向对象的装饰者模式不一样,但更符合JS的语言特色
1 | var obj = { |
JS模拟传统面向对象的装饰者模式
假设我们在编写一个飞机大战的游戏,随着经验值的增加,我们操作的飞机对象可以升级成更厉害的飞机,一开始这些飞机只能发射普通的子弹,升到第二级时可以发射导弹,升到第三级时可以发射原子弹。
1 | // 建立一架飞机 |
装饰类
1 | var MissileDecorator = function( plane ){ //以飞机对象为参数 |
测试
1 | var plane = new Plane(); |
说明:
导弹类和原子弹类的构造函数保存plane对象
- 在他们的fire方法中调用plane参数的fire方法,并进行扩展
这种方式动态给对象添加职责,并没有改变对象本身,而是将对象放入另一个对象中,对象以一条链的方式调用,形成一个聚合对象
- 这些聚合对象必须提供统一的接口(上面例子中的fire方法)
- 对使用这些对象的客户来说聚合则是透明的,不需要了解对象是否被装饰过
JavaScript的装饰者
JS并不需要用类来实现装饰者
1 | var plane = { |
装饰函数
JS中,几乎一切都是对象,函数也是对象。
- 很容易给对象动态添加属性和方法,但很难在不改动源码的情况下给函数加一些额外的功能。
若直接改写函数,则违背开闭原则
1 | var a = function(){ |
很多时候我们都不希望去改动原有的函数,改动后可能发生意想不到的影响。
- 可以通过保存原引用的方式对函数进行拓展
1 | var a = function(){ |
保存原引用的方式是开发中比较常见的方式
例如,我们想给window添加onload事件,但不确定这个事件是否已经被其他人绑定过,为了避免覆盖别人的window.onload,我们一般都会采用以下的方法
1 | var _onload = window.onload || function(){}; //保存原来的方法,若无则用默认函数 |
以上方式符合开闭原则,但存在两个问题
- 必须维护中间变量,例如上面的
_onload
- 装饰链越长,保存的变量就会越多,装饰函数也越多
- 还可能发生this劫持(预期的this是a,结果在调用时变成了b)
- 上面的onload没有,因为调用_onload()时,this也是指向window
1 | var _getElementById = document.getElementById; // _getElementById是一个全局函数,当调用一个全局函数时,this是指向window |
1 | // 对上面代码进行改进 |
这样做显然很不方便,下面我们引入AOP,来提供一种完美的方法给函数动态增加功能
用AOP装饰函数
AOP(Aspect Oriented Programming):面向切面编程
- 通过预编译方式和运行期间动态代理实现程序功能的统一维护的一种技术
- 利用AOP可以对业务逻辑的各个部分进行隔离,从而使得业务逻辑各部分之间的耦合度降低,提高程序的可重用性,同时提高了开发的效率
(百度百科)
这里就不赘述
定义两个方法:
- Function.prototype.before方法
- 在原函数执行前执行
- 接受一个函数当作参数,这个函数即为新添加的函数,它装载了新添加的功能代码
- Function.prototype.after方法
- 在原函数执行后执行
1 | Function.prototype.before = function( beforefn ){ |
使用示例
1 | <html> |
上面的onload也用该方法
1 | window.onload = function(){ |
上面的AOP方法会污染原型,因此许多人不喜欢这样做
可以做以下修改
- 把原函数和新函数都作为参数传入before或者after方法
1 | var before = function( fn, beforefn ){ |
AOP的应用实例
用AOP装饰函数的技巧在实际开发中非常有用。
不论是业务代码的编写,还是在框架层面,我们都可以把行为依照职责分成粒度更细的函数,随后通过装饰把它们合并到一起,这有助于我们编写一个松耦合和高复用性的系统。
数据统计上报
分离业务代码和数据统计代码,无论在什么语言中,都是AOP的经典应用之一。
在项目开发的结尾阶段难免要加上很多统计数据的代码,这些过程可能让我们被迫改动早已封装好的函数。
比如页面中有一个登录button,点击这个button会弹出登录浮层,与此同时要进行数据上报,来统计有多少用户点击了这个登录button
1 | <html> |
在showLogin函数里,既要负责打开登录浮层,又要负责数据上报,这是两个层面的功能,在此处却被耦合在一个函数里。
对以上代码进行AOP分离
1 | <html> |
用AOP动态改变函数的参数
1 | Function.prototype.before = function( beforefn ){ |
从这段代码的(1)处和(2)处可以看到,beforefn和原函数self共用一组参数列表arguments,当我们在beforefn的函数体内改变 arguments的时候,原函数self接收的参数列表自然也会变化。
- 共用arguments
1 | var func = function( param ){ |
示例
有一个用于发起ajax请求的函数,这个函数负责项目中所有的ajax异步请求
1 | var ajax = function( type, url, param ){ |
突然有一天,我们网站受到了CSRF攻击
- 解决CSRF攻击最简单的一个办法就是在HTTP请求中带上一个Token参数
于是,写一个用于生成Token的函数
1 | var getToken = function(){ |
给每个ajax请求都加上Token参数
1 | var ajax = function( type, url, param ){ |
出现一些问题:ajax函数相对变得僵硬
- 每个从ajax函数里发出的请求都自动带上了Token参数,虽然在现在的项目中没有什么问题,但如果将来把这个函数移植到其他项目上,或者把它放到一个开源库中供其他人使用,Token参数都将是多余的
- 也许另一个项目不需要验证Token,或者是Token的生成方式不同
上面无论是哪种情况,都必须重新修改ajax函数
为了解决这个问题,先把ajax函数还原成一个干净的函数
1 | var ajax= function( type, url, param ){ |
把Token参数通过Function.prototyte.before装饰到ajax函数的参数param对象中
1 | var getToken = function(){ |
用AOP的方式给ajax函数动态装饰上Token参数,保证了ajax函数是一个相对纯净的函数,提高了ajax函数的可复用性,它在被迁往其他项目的时候,不需要做任何修改
区分装饰者模式和代理模式
装饰者模式和代理模式的结构看起来非常相像,这两种模式都描述了怎样为对象提供一定程度上的间接引用,它们的实现部分都保留了对另外一个对象的引用,并且向那个对象发送请求。
代理模式和装饰者模式最重要的区别在于它们的意图和设计目的。
- 代理模式的目的是,当直接访问本体不方便或者不符合需要时,为这个本体提供一个替代者。本体定义了关键功能,而代理提供或拒绝对它的访问,或者在访问本体之前做一些额外的事情。装饰者模式的作用就是为对象动态加入行为。
- 换句话说,代理模式强调一种关系(Proxy与它的实体之间的关系),这种关系可以静态的表达,也就是说,这种关系在一开始就可以被确定。
- 装饰者模式用于一开始不能确定对象的全部功能时。代理模式通常只有一层代理-本体的引用,而装饰者模式经常会形成一条长长的装饰链。
在虚拟代理实现图片预加载的例子中,本体负责设置img节点的src,代理则提供了预加载的功能,这看起来也是“加入行为”的一种方式,但这种加入行为的方式和装饰者模式的偏重点是不一样的。装饰者模式是实实在在的为对象增加新的职责和行为,而代理做的事情还是跟本体一样,最终都是设置src。但代理可以加入一些“聪明”的功能,比如在图片真正加载好之前,先使用一张占位的loading图片反馈给客户。
最后
通过数据上报、统计函数的执行时间、动态改变函数参数例子,我们了解了装饰函数,它是JavaScript中独特的装饰者模式。这种模式在实际开发中非常有用,除了上面提到的例子,它在框架开发中也十分有用。作为框架作者,我们希望框架里的函数提供的是一些稳定而方便移植的功能,那些个性化的功能可以在框架之外动态装饰上去,这可以避免为了让框架拥有更多的功能,而去使用 一些if、else语句预测用户的实际需要。