利用原型链实现优雅的JavaScript兼容层

传统兼容方案的局限性

构建底层接口兼容方案时，核心思路通常是通过条件判断来确认客户端支持的具体接口。一个经典的案例涉及事件处理机制：

 
var addEvent = function(e, what, how) {
if (e.addEventListener) e.addEventListener(what, how, false)
else if (e.attachEvent) e.attachEvent('on' + what, how)
} 

上述代码涵盖了元素绑定事件时可能遇到的两种主要情况：标准的W3C DOM接口以及DHTML提供的旧版接口。尽管该示例较为简略，但足以说明问题所在。

早期的兼容层做法是在调用时进行实时判断，并进入相应的if分支。显然，这种“运行时判断”的方式效率较低。随后，业界采用了一种优化策略：

 
if (MSIE) {
addEvent = function(e, what, how) {
e.attachEvent('on' + what, how);
} 
} else {
addEvent = function(e, what, how) {
e.addEventListener(what, how);
} 
} 

这种策略通过一次性判断，将addEvent绑定到不同的实现代码上，从而免去了后续运行时的分支判断开销。

然而，这种方法存在显著缺陷。首先，将“使用attachEvent”与“客户端为MSIE”强绑定是一种过时的思维。如果微软更新策略怎么办？事实是，IE9明确支持了DOM接口，甚至支持DOM3。这种“良心发现”式的更新会破坏许多前端库的代码，迫使它们进行修改（正如IE8发布时发生的情况）。此外，该方法未考虑“未知客户端”——例如Chrome发布后，许多类库不得不重写代码。

特性检测的解耦思路

那么，特性检测应如何正确实施？特性检测旨在最大限度地减少“新客户端”带来的干扰——通过在类库初始化阶段定义一组代码来检测客户端具备的特性，并利用这些检测结果绑定类库代码：

 
var supportsAddEventListener = !!(checkerElement.addEventListener);
if (supportsAddEventListener) {
addEvent = function(e, what, how) {
e.addEventListener(what, how);
} 
} else if (supportsAttachEvent) {
addEvent = function(e, what, how) {
e.attachEvent('on' + what, how);
} 
} 

特性检测的核心在于将“使用特定客户端”与“支持特定特性”解耦——让if分支直接针对“特性有无”（即接口是否一致）进行判断，从而消除因客户端制造商策略调整而导致的“好心办坏事”。事实上，这也是顺应历史潮流的选择——当标准接口逐渐普及，客户端之间的“表征”趋于一致时，构建一个统一的兼容层接口是合理之举。

基于原型链的优雅兼容实现

让我们重新审视这些代码。通常，利用特性检测进行兼容的代码结构如下：

 
if (new_interface_detected) {
comp = function() {uses_new_interface};
} else if (old_interface_detected) {
comp = function() {uses_old_interface};
} else {
throw new Error('Unadaptable!')
} 

换言之，处理流程为：

如果客户端支持新接口，则将兼容层绑定到新接口上

否则，如果客户端支持老接口或不一致接口，则将兼容层绑定到老接口上

否则，若可能，返回错误提示

也就是说，兼容层程序如同从高空“跌落”，如果客户端支持“高级”特性（新接口、标准接口），它就会被“接住”——兼容层由此找到归宿；否则继续向下掉落——若老接口接住了，则使用老接口；如果始终无人接住，便会“啪”地摔在地上，并最后喊一声：“你用的客户端太小众，我无能为力！”

这让人联想到什么？事实上，如果你了解JavaScript对象系统的机理，就可以将其类比：这正是原型机制！原型系统利用这种“跌落”——查找某个成员，如果该对象中已定义，则返回之；否则沿原型链向上搜索（这次是向上的），如此重复，直到原型链尽头，返回undefined。

说做就做！这里同样以addEvent为例。首先，我们定义一个空驱动，其中不包含任何内容：

var nullDriver = {}然后，创建一个对象，并将原型链指向它。在ECMA V5时代，我们可以使用Object.create，但遗憾的是，目前仍有大量老旧客户端（否则无需进行兼容处理），因此需要自行craft一个函数：

 
var derive = Object.create ? Object.create: function() {
var T = function() {};
return function(obj) {
T.prototype = obj;
return new T
} 
}() 

这种用法可能显得怪异，但它运行无误，且速度不慢——能达到Object.create的一半。我们就用这个derive函数来启动：

 
var dhtmlDriver = derive(nullDriver);
var dhtmlDriverBugfix = derive(dhtmlDriver);这里的bugfix是针对某些“bug”和特殊情况定义的特别Driver。此处可忽略它。好了，DHTML中的addEvent是什么样子？
if (supportsAttachEvent) {
dhtmlDriver.addEvent = function(e, what, how) {
e.attachEvent('on' + what, how)
} 
} 

接下来呢？原型链最前端应该是W3C的标准驱动，写上！

 
var w3cDriver = derive(dhtmlDriverBugfix);
var w3cDriverBugfix = derive(w3cDriver);
if (supportsAddEventListener) {
w3cDriver.addEvent = function(e, what, how) {
e.addEventListener(what, how)
} 
} 

最后，我们放置一个最终调用接口。（因为w3cDriverBugfix名称难听……）

 
var driver = derive(w3cDriverBugfix);

然后进行调用即可。看，这使得那些冗长的分支判断变得简单有效，同时保留了fallback特性：在支持addEventListener的环境上调用addEvent，等价于调用w3cDriver.addEvent；而在不支持addEventListener的客户端上，则会“跌落”到底层，例如调用dhtmlDriver.addEvent。此外，进行bugfix也很容易——可以在专门的“bugfix”层进行hook，而原有层完全不受影响。

等等，继承这么多层会很慢吗？诚然，那么深的原型链确实会慢，但我有办法。还记得给对象属性写入时会发生什么吗？

 
var ego = function(x) {return x}
for (var each in driver) {
if (! (each in nullDriver)) {
driver[each] = ego(driver[each])
} 
} 

没错，原来高悬在原型链上的方法会“哗”地一下掉到最底层！这回无需沿原型链向上搜索，直接从最底端获取属性即可。这里使用ego函数的原因是防止某些浏览器“优化掉”这段代码。

总结：虽然这里讨论的是兼容，但其精华在于语言特性——利用原型继承，我们可以优雅地完成这一令人头疼的操作。是的，框架的美感不应只在外表，其内部——即使是最令人烦躁的内部——同样需要优雅。

这里的技术可以在dess中找到。