jQuery中的编程范式详解

很有意思的是, jQuery的实现代码中明显有很多是接力触发代码: 如果需要执行下一个动画就取出执行, 如果需要启动timer就启动timer等. 这是因为js程序是单线程的,真正的执行路径只有一条,为了保证执行线索不中断, 函数们不得不互相帮助一下. 可以想见, 如果程序内部具有多个执行引擎, 甚至无限多的执行引擎, 那么程序的面貌就会发生本质性的改变. 而在这种情形下, 递归相对于循环而言会成为更自然的描述.nbsp;
nbsp;
9. promise模式：因果关系的识别

现实中,总有那么多时间线在独立的演化着, 人与物在时空中交错,却没有发生因果. 软件中, 函数们在源代码中排着队, 难免会产生一些疑问, 凭什么排在前面的要先执行#63; 难道没有它就没有我#63; 让全宇宙喊着1,2,3齐步前进, 从上帝的角度看,大概是管理难度过大了, 于是便有了相对论. 如果相互之间没有交换信息, 没有产生相互依赖, 那么在某个坐标系中顺序发生的事件, 在另外一个坐标系中看来, 就可能是颠倒顺序的. 程序员依葫芦画瓢, 便发明了promise模式.

promise与future模式基本上是一回事,我们先来看一下java中熟悉的future模式.
复制代码 代码如下:futureResult = doSomething();
nbsp; ...
nbsp; realResult = futureResult.get();

发出函数调用仅仅意味着一件事情发生过, 并不必然意味着调用者需要了解事情最终的结果. 函数立刻返回的只是一个将在未来兑现的承诺(Future类型), 实际上也就是某种句柄. 句柄被传来传去, 中间转手的代码对实际结果是什么,是否已经返回漠不关心. 直到一段代码需要依赖调用返回的结果, 因此它打开future, 查看了一下. 如果实际结果已经返回, 则future.get()立刻返回实际结果, 否则将会阻塞当前的执行路径, 直到结果返回为止. 此后再调用future.get()总是立刻返回, 因为因果关系已经被建立, [结果返回]这一事件必然在此之前发生, 不会再发生变化.

future模式一般是外部对象主动查看future的返回值, 而promise模式则是由外部对象在promise上注册回调函数.
复制代码 代码如下:function getData(){
nbsp;nbsp; return $.get('/foo/').done(function(){
nbsp;nbsp;nbsp;nbsp;nbsp; console.log('Fires after the AJAX request succeeds');
nbsp;nbsp; }).fail(function(){
nbsp;nbsp;nbsp;nbsp;nbsp; console.log('Fires after the AJAX request fails');
nbsp;nbsp; });
nbsp; }
nbsp;
nbsp; function showDiv(){
nbsp;nbsp;nbsp; var dfd = $.Deferred();
nbsp;nbsp;nbsp; $('#foo').fadeIn( 1000, dfd.resolve );
nbsp;nbsp;nbsp; return dfd.promise();
nbsp; }
nbsp;
nbsp; $.when( getData(), showDiv() )
nbsp;nbsp;nbsp; .then(function( ajaxResult, ignoreResultFromShowDiv ){
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; console.log('Fires after BOTH showDiv() AND the AJAX request succeed!');
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; // 'ajaxResult' is the server's response
nbsp;nbsp;nbsp; });

jQuery引入Deferred结构, 根据promise模式对ajax, queue, document.ready等进行了重构, 统一了异步执行机制. then(onDone, onFail)将向promise中追加回调函数, 如果调用成功完成(resolve), 则回调函数onDone将被执行, 而如果调用失败(reject), 则onFail将被执行. when可以等待在多个promise对象上. promise巧妙的地方是异步执行已经开始之后甚至已经结束之后,仍然可以注册回调函数

someObj.done(callback).sendRequest() vs. someObj.sendRequest().done(callback)

callback函数在发出异步调用之前注册或者在发出异步调用之后注册是完全等价的, 这揭示出程序表达永远不是完全精确的, 总存在着内在的变化维度. 如果能有效利用这一内在的可变性, 则可以极大提升并发程序的性能.

promise模式的具体实现很简单. jQuery._Deferred定义了一个函数队列，它的作用有以下几点：

A. 保存回调函数。
B. 在resolve或者reject的时刻把保存着的函数全部执行掉。
C. 已经执行之后, 再增加的函数会被立刻执行。
nbsp;
一些专门面向分布式计算或者并行计算的语言会在语言级别内置promise模式, 比如E语言.
复制代码 代码如下:def carPromise := carMaker lt;- produce("Mercedes");
nbsp;nbsp;nbsp;nbsp; def temperaturePromise := carPromise lt;- getEngineTemperature()
nbsp;nbsp;nbsp;nbsp; ...
nbsp;nbsp;nbsp;nbsp; when (temperaturePromise) -gt; done(temperature) {
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; println(`The temperature of the car engine is: $temperature`)
nbsp;nbsp;nbsp;nbsp; } catch e {
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; println(`Could not get engine temperature, error: $e`)
nbsp;nbsp;nbsp;nbsp; }
在E语言中, lt;-是eventually运算符, 表示最终会执行, 但不一定是现在. 而普通的car.moveTo(2,3)表示立刻执行得到结果. 编译器负责识别所有的promise依赖, 并自动实现调度.nbsp;
nbsp;
10. extend: 继承不是必须的

js是基于原型的语言, 并没有内置的继承机制, 这一直让很多深受传统面向对象教育的同学们耿耿于怀. 但继承一定是必须的吗#63; 它到底能够给我们带来什么#63; 最纯朴的回答是: 代码重用. 那么, 我们首先来分析一下继承作为代码重用手段的潜力.

曾经有个概念叫做"多重继承", 它是继承概念的超级赛亚人版, 很遗憾后来被诊断为存在着先天缺陷, 以致于出现了一种对于继承概念的解读: 继承就是"is a"关系, 一个派生对象"is a"很多基类, 必然会出现精神分裂, 所以多重继承是不好的.
复制代码 代码如下:class A{ public: void f(){ f in A } }
nbsp;nbsp; class B{ public: void f(){ f in B } }
nbsp;nbsp; class D: public A, B{}

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!