js自定义消息机制研究学习(三)——插件化我们js开发前两篇 js自定义消息机制研究学习(二)——做一些改动,定制自己的消息机制 研究了一些基础的自定义消息机制,对一些简单的开发已经足够。 现在我们来尝试面对一些稍微复杂一些的架构设计。 首先,增加了一个插件模式: ![]() ![]() var plugs=(function(){ 如果你看过前两篇代码,这段代码是比较容易看懂的。它为传入的对象(或函数)首先绑定了monitor模式,然后为对象增加了两个方法:addPlugs,installPlugs addPlugs 添加插件 installPlugs 安装插件 添加插件很简单,只是把实体装到一个{}键值对中 安装插件,就会调用每个插件对象的:install方法 为什么要有插件模式呢?我们举个例子来说明 虚构一个需求: 1. 在页面上动画展示龟兔赛跑 2.兔子和乌龟可以说话 3.展示他们比赛过程 这里我没什么素材,只简单展示一下这个程序设计 第一步,我们构造一个Animal函数,作为兔子、乌龟的类,代码如下 ![]() ![]() ///动物 我们现在有一个动物的类(Animal),它有一些行为:说(say),停(stop),跑(run),左转(turnLeft),右转(turnRight) 因为我在代码里使用了trigger的方法,我们先使用上一篇讲到monitor,初始化一下: monitor.ini(Animal); 第二步 我们先写一个记录的功能,用来记录动物对象的言行,这里只记录say,stop,turn的消息,代码如下: ![]() ![]() ///记录器 我们这里用id=log的一个页面元素(div)来显示动物的言行 第三步,我们来创建兔子与乌龟这两个对象: var hare=new Animal({name:"兔子"}); 第四步,我们将记录器绑定到两个对象上 如果你要绑定到所有动物对象上,你可以使用上一篇讲到的live方法。在这里为了说明为什么要用插件,我们限定一下需求,假设live是不允许使用的,因为我们还要创建其他的一些动物,Logger是不需要记录这些非主角的行为。那么我们要编写如下的代码: ![]() ![]() var log=new Logger(); 现在提出一个问题,你如果仔细看的话,我们发现在介于live和bind之间,比如有100个Animal对象,我们只要求记录50个Animal的行为,那么我们该有多郁闷,我们需要写很多的bind,假如我们Animal不只这几个行为,我们为它扩展了100个行为,都要做记录,如果一行行的写bind,该多恐怖 好吧,改进一下,你或许会建议要函数,例如这样: ![]() ![]() function bindLog(ani) 如果只有一两个这样的需求,这样也是不错的。那么再扩展呢?要写很多个,比如十个,类似于Logger的类,他们要去绑定100个Animal一个,数个,或者全部(全部当然可以考虑live) 假设这个十个类,有些需要每一个Animal对象都绑定单独的对象,比如我们写一个类Display,它来代表显示在屏幕上的动物,那么一个动物对象就需要对应一个Display 很快我们就会发现,我们需要写很多的类似于bindLog的方法。如bindDisplay,bindRun等等充斥在我们的主代码中 那么用开篇写插件,我们会怎么做? 首先把monitor.ini(Animal);修改为:plugs.ini(Animal)让它支持插件模式,因为插件模式默认绑定了monitor,所以我们不需要再初始化一次monitor
![]() ![]() install:function(main){ 我们的绑定代码,修改成如下: ![]() ![]() //添加安装插件 我们把一系列的bind,修改成为先使用addPlugs,最后调用installPlugs来完成。 这样做的优势? 你的主代码很清晰,完整如下: ![]() ![]() var hare=new Animal({name:"兔子"}); 这样,你很快就能看明白对象与对象之间的关系,也能从更高一点抽象层次上去组织你的对象,组织你的代码,而不需要头疼写一堆一堆的bind了,如果你要换掉一个Logger,比如换成一个只记录say的Logger 或者说你要把动物说的话以气泡的形式显示在他们的头顶。 当我们有很多的组件拼装时,这样模式很给我们带来很大的便利。 更重要的: Animal 可以看做一个业务逻辑,我们很好的将它与显示进行了分离,在测试中,我们可以很简单的调用hare.run hare.say,而完全不用关心他们的显示表现,这样可以让我们在更高的抽象层次构建我们的js程序。对于一些复杂的业务,既可以让我们专注于业务,也可以让我们彼此分工合作,各写一块。 PS: 也许有人要问,为什么要addPlugs,然后再installPlugs,而不是一个addPlugs直接搞定。 在例子写完以后我发现了这个问题,这是我的疏忽,惯性思维让我沿用了我的实际使用的plugs。 其实我应用的plugs,还有一些扩展方法,如getPlug等等,在实际开发中插件的install方法后还会触发trigger一个消息等等 这样做的目的是,在installPlugs时,部分插件的安装,是需要知道其他插件的存在 还有一个原因,是涉及懒加载的,在addPlugs时,有时我会addPlugs一个配置,或者一个简称,然后有他们实际指向的js文件此时并未加载 直到installPlugs时,它才会真正加载js并创建plug对象。所以我是在插件配置都准备好的情况下,才请求相应的js文件(比如直接请求一个服务器合并多个js后的压缩文件) 希望不要给大家造成困扰。 完整代码示例:下载 在完整代码示例中,我增加了一个Display用于显示动物,然后抱着玩的心态加了段简单的故事脚本,博君一笑 |
|
来自: BlazerOfIT > 《我的图书馆》