【发布时间】:2012-06-01 05:10:28
【问题描述】:
回顾:
好的,我已经有一段时间没有问这个问题了。像往常一样,我还是去增加了Object.prototype,尽管这里和网络上其他地方都有反对它的所有有效论据。我想我就是那种固执的混蛋。
我试图想出一个确凿的方法来防止新方法破坏任何预期的行为,这被证明是一件非常困难但信息丰富的事情。
我学到了很多关于 JavaScript 的知识。至少我不会尝试像弄乱本机原型那样鲁莽的事情(除了String.prototype.trim 用于 IE
在这种特殊情况下,我不使用任何库,因此冲突不是我主要关心的问题。但是在玩弄原生原型时,我对可能发生的事故进行了更深入的研究,因此我不太可能将这段代码与任何库结合起来尝试。
通过研究这种原型方法,我对模型本身有了更好的理解。我将原型视为某种形式的灵活的传统抽象类,使我坚持传统的 OOP 思维。这种观点并没有真正做到原型模型公正。道格拉斯·克罗克福德 (Douglas Crockford) 写过这个陷阱,遗憾的是,粉红色的背景让我无法阅读全文。
我决定更新这个问题,以免阅读本文的人很想亲眼看看。我只能说:无论如何,做。我希望你在决定放弃这个相当愚蠢的想法之前,像我一样学习一些简洁的东西。一个简单的函数可能同样有效,甚至更好,尤其是在这种情况下。毕竟,它的真正美妙之处在于,只需添加 3 行代码,您就可以使用相同的函数来增强特定对象的原型。
我知道我要问一个已经存在了很长一段时间的问题,但是:为什么 Object.prototype 被认为是禁区?它就在那里,并且可以像任何其他原型一样进行增强。那么,为什么不应该利用这一点。在我看来,只要你知道自己在做什么,就没有理由避开 Object 原型。
以这个方法为例:
if (!Object.prototype.getProperties)
{
Object.prototype.getProperties = function(f)
{
"use strict";
var i,ret;
f = f || false;
ret = [];
for (i in this)
{
if (this.hasOwnProperty(i))
{
if (f === false && typeof this[i] === 'function')
{
continue;
}
ret.push(i);
}
}
return ret;
};
}
基本上,它与旧的for...in 循环相同,您可以在函数中保持安全,或者一遍又一遍地编写。我知道它将被添加到 all 对象中,并且由于 JavaScript 中的几乎每个继承链都可以追溯到 Object.prototype,但在我的脚本中,我认为它是两害相权取其轻。
也许,有人可以比this chap 更好地告诉我哪里错了。
在寻找人们 不 接触 Object 原型的原因时,不断出现一件事:它打破了 for..in 循环,但话又说回来:许多框架确实如此,更不用说你自己的继承链了。因此,在我看来,在循环遍历对象的属性时不包括 .hasOwnProperty 检查是不好的做法。
我还发现this 很有趣。再说一遍:有一条评论非常明确:扩展原生原型是不好的做法,但如果 V8 人这样做,我还能说他们错了吗?
我知道,这个论点并不完全成立。
重点是:我看不出上面的代码有什么问题。我喜欢它,经常使用它,到目前为止,它没有让我失望过一次。我什至正在考虑将更多功能附加到对象原型。除非有人能告诉我为什么我不应该这样做。
【问题讨论】:
-
我从来没有想过这个。但是哪些框架打破了
for...in循环?请详细说明我自己的“继承链”如何打破for...in?我不是想固执己见,我只是不明白这些例子是如何打破for...in循环的。也许是一个例子?其他框架和自定义继承中断的示例for...in。 -
谁对我的问题投了反对票:请解释一下原因
-
喜欢更新的部分:D
标签: javascript prototype