这个方法，是有传统 OO 思想的程序员情节，对于 JS 本身来说，uber 没啥用。这也就是为何 DC 说 8 年没用一次的原因。

JS 有更简洁方便继承体系，《JavaScript: The Good Parts》中的 inherits 是一种。

首先是DC在他的网站上发表了一篇有关Javascript继承文章: Classical Inheritance in JavaScript，其中提出了inherits方法，这个方法实现很复杂，其中有包含有uber方法；
结果chensheng发现了其中关于uber方法的一个错误，发表在CSDN上，时间是2006年12月28日；
John Hax 与2006年12月31日在CSDN上连续发表评论，并且给出修正方法，同时还在在英文网站上给出修正；
DC不知何时（估计是2007年）看到了John Hax的文章，并且修改了最初的文章，完全采用了Hax的修正（但是没有任何感谢Hax的表示，这让Hax很不高兴），DC同时在他的文章最后补充说：他写了8年的Javascript，从来没有用过uber方法，（这是否意味着uber方法没什么实际用途，大家都在瞎忙活？我不太懂）；
在这篇文章中，lifesinger似乎又发现了uber方法的另一个漏洞或陷阱（这一点我不是很确定，麻烦lifesinger再确认一下，应为感觉uber方法没什么用途，所以本人还没有认真阅读）。
后话：
DC在2008年出版了他的大作Javascript: The Good Parts，有中文版，译者之一（小马）应该是lifesinger的同事。在书中的48页，提到了inherits方法，这一回的inherits实现很简单，完全没有提到uber方法，我不清楚DC为什么这么做？是不是因为DC发现复杂的uber方法根本没有用，而且很容易出错，干脆拿掉算了，这一点希望高手指点迷津。
象DC这样的大师或大牛，我们当然要多学习他们的文章或者观点，但是我们可能也还要保持独立的观点，大师也是人，也会犯错，而大师一犯错，错误也会是影响深远的。比如这个uber方法，Javascript的另一个大人物John Resig就在他的大作中（Pro JavaScript Techniques，也有中文版了）完全引用了uber方法（书中第3章），而且引用的是DC的错误的老版本（可惜了，又一个错误被大人物传开了，而且这个错误的东西似乎没有多大的用处）。

oo没错，但用传统的类模型套在javascript的原型模式上，总感觉有点别扭。为什么一定要子类、父类这些概念呢？this.super真的必须吗？

归根结底，我们要解决的问题是提高代码的可复用、可维护和可扩展。只要能达到目标就行，管它面向过程还是面向对象呢。传统的类模式的确能非常好的解决这些问题，因此在针对原型模式的设计模式总结出来之前，模拟类模型是最简单的一条路

但原型模式、动态语言，毕竟不同于传统的C++, Java, 更多的是一种编程思想的转变。怎样适应这种转变？在动态编程思想下怎样体现传统oo里的设计模式甚至创造出新的更好的模式？我觉得这些是很值得研究的。

存在即合理，但存在的未必是好的，人民群众有这个需求，也许是因为人民群众还未找到新的路，只好依着老路子走罢了……

呵呵。偶从csdn搬到blogspot用了一段时间，不过因为被墙了，就很少去更新了。BTW，dc同志拿了我的补丁也不打招呼，偶心里很不爽的说，所以偶要坚定自己坚决不用yahoo和YUI的决心……

搞笑完毕，说说正题。

dc的继承方案也只是万马奔腾中的一种。实际上有许多其他非常有意思的oo方案。譬如dean edwards的base。这个方案的特点是继承链是基于一个精心构造的base基类，相当于搞了一个Object2，而不会影响传统的Object的继承模式。另一个例子是prototype 1.6开始的Class继承，其特点是通过对源代码的分析来重写方法使之支持super调用（参见：http://hax.javaeye.com/blog/167131 ），缺点是函数被包装了一层，可能存在潜在的问题。其他的方式也有，譬如爱民的qomo框架是编写了一个通用的base方法，然后再其中通过Function.caller回溯调用链来找到应该调用哪个的父类方法，缺点是依赖caller这个非ECMA标准特性。

总而言之，偶并不完全赞同dc的看法。存在的就是合理的。各个框架都搞oo方案，说明人民群众有这个需求。。。