javascript事件系统的发展史2

综观一个系统的发展，无非是发现一个问题就把它独立出来解决掉，因此它的所有模块（或者分支）其实针对独立的问题，这样我们对这些问题若有什么更好的解决方法，替换相应的模块便是，要不代码混杂在一起没法看了。上一部分就提到了，attachEvent的事件列队出了些问题，我们要手动构建列队了。所谓列队就是有先有后的问题，因此DE大神搞了一个全局的uuid，分配给每个回调函数。但要注意，每个回调所针对的事件源与事件类型，因此这不可能一个数组搞定。看下图：
el.attachEvent("onmouseenter",function(){alert(window.event.type)})
| | | | |
| | | | |
事件源 监听器 事件类型 回调函数 事件对象
事件源，其实el也一定是事件源，如某同类型事件从文档树下冒泡上来，或者顶层对象要捕获它下面的某个同类型事件，那它就成了currentTarget。为简单起见，我称它为事件源。这个事件源可以绑定很多监听器，每个监听器可以针对不同的事件类型，当然这也意味着有许多回调函数。当我们发现attachEvent多个同类型事件时，回调函数的次序出错时，意味着，如果我们还要它时，每种事件类型只能绑定监听器一次。那不就意味着，一个监听器只有一个回调函数，因为只有一个次序肯定不会出错！但怎么添加更多回调函数呢？嗯，我们需要一个数组。数组里面的回调函数才是我们自己添加的，然后一个for循环执行它们就是！
var queue = [];
el.attachEvent("onmouseenter",function(){
var e = window.event;
for(var i=0,n=queue.length;i<n;i++){
queue[i].call(this,e)//queue[i]为我们自己的回调函数，this指向el
}
});
queue.push(callback)
这样就实现监听事件与添加回调函数相分离。但是一个事件类型就要搞一个queue，而且这些事件类型即使是同一类型还有事件源之分。那会产出巨量的全局变量。因此我们必须找个地方放置它们。DE大神在要监听的每个元素节点（或者文档对象什么的）上设置一个events属性，那是一个对象，然后以type-object的形式保存，type即为事件类型，object为一个对象，键为他的那个uuid，值为回调函数。下面是他的addEvent函数的一部分，完整代码这里（要翻墙）：
function addEvent(element, type, handler) {
if (!handler