原生原型与$ .extension（） [英] Native prototypes vs $.extension()
问题描述
在工作中，我们使用jQuery。在我们开始使用它之后不久，我看到一些开发人员正在向文件jquery-extensions.js添加函数。在里面，我发现了一大堆方法添加到 $ ，基本上相当于jQuery上的静态方法。这里有几个：
At work, we use jQuery. Shortly after we started using it, I saw that a couple developers were adding functions to a file jquery-extensions.js. Inside, I found a whole bunch of methods added to $ that essentially amount to static methods on jQuery. Here's a few:
$.formatString(str, args) {
...
}
$.objectToArray(obj) {
...
}
等。 他们实际上都没有使用任何与jQuery 相关的东西。这让我很奇怪。
Etc. None of them actually use anything to do with jQuery. This struck me as odd.
最后，我们需要在我们的库中使用一个函数来本地化日期。我的解决方案是创建：
Eventually, we needed a function in our library to localize dates. My solution was to create:
Date.prototype.toLocaleDate = function() {
...
}
Date.parseLocalDate = function() {
...
}
这样做之后不久，我找到一位高级开发人员来找我问我认为我在做什么。他告诉我，在这里，我工作的地方，我们不创造原型，因为它们是邪恶的。他给出的唯一理由是它们基本上是一种糟糕的语言特征，因为它们可能被滥用并且看到原型会很困惑（例如，我如何知道新的Date（）。toLocaleDate（）是原型而不是原生的ECMAScript ）。通过使用 $ .formasString（...）而不是blah blah.formatString（...），我们明确表示任何带有$的东西都不是本机JavaScript的一部分。
Shortly after doing this, I get a Sr. Developer coming up to me asking me what I think I'm doing. He tells me that here, where I work, we don't create prototypes because they're evil. The only reasons he gave was that they're fundamentally a poor language features because they "can be abused" and that it's confusing to see prototypes (e.g. how do I know new Date().toLocaleDate() is a prototype and not native ECMAScript). By using $.formatString(...) instead of "blah blah".formatString(...), we're keeping it clear that anything with a $ is not part of native JavaScript.
这些原因看起来有点傻，但我提出妥协，所以他不会必须记住方法是否是原型—在原型函数名称前加上 $ ：
Those reasons seem a bit silly, but I offered a compromise so he wouldn't have to remember whether a method was an prototype—prefix the prototype function name with $:
String.prototype.$format = function() {
...
}
"blah blah".$format(...);
很快被解雇了，现在我不得不在各处添加这些$ .myPrototypeAsAFauxStaticMethodOnjQuery（）函数。
That was quickly dismissed and now I'm having to add these $.myPrototypeAsAFauxStaticMethodOnjQuery() functions everywhere.
我是唯一认为这种做法很愚蠢的人吗？
Am I the only one that thinks this practice is stupid?
推荐答案
原生原型辩论有点累，双方都有有效的观点，我会试着总结一下，希望看到大局可能有用。
The native prototypes debate is a bit tired, there are valid points on both sides, I'll try to summarize them in hope it might be useful to see the big picture.
contra 没有必要扩展原生原型。你有你需要的一切。
pro JS标准库很少见。数组和字符串缺少许多重要功能。
contra There's no need to extend native prototypes. You've got everything you need.
pro JS standard library is scarce to the extreme. Arrays and strings are lacking many vital features.
contra 使用函数或您自己的命名空间。
pro 类似的方法 foo.trim（）比 org.blah.trim（foo）这样的函数更符合语言的精神。一切都是javascript中的对象，让它成为那样。
contra Use functions or your own "namespaces".
pro Methods like foo.trim() are far more in the spirit of the language than functions like org.blah.trim(foo). Everything is object in javascript and let it be that way.
contra 本地JS对象是语言设计者的保留。我们的方法可能会意外地覆盖新添加的内置函数。
pro 打开对象是一个很棒的功能，如果不使用它就很傻。新的Javascript版本不是每天都会发生的事情，并且标准的添加事先是众所周知的。
contra Native JS objects are "reserved" for the language designers. Our methods can accidentally override newly added built-ins.
pro Open objects is a great feature and it would be silly not to use it. A new Javascript version is not something that happens every day and additions to the standard are well known in advance.
contra 扩展原生原型令人困惑，因为我们和本机方法之间没有区别。
pro JS标准库很小且记录良好。我们javascript开发人员应该知道本机方法的名称。
contra Extending native prototypes is confusing, because there's no distinction between our and native methods.
pro JS standard library is small and well documented. We javascript developers are supposed to know native methods' names.
contra 扩展原型可能导致名称空间冲突。
pro 是的，但这可能发生在全局函数或众所周知的全局对象（如 $ ）中。
contra Extending prototypes can lead to namespace conflicts.
pro Yes, but this can happen with global functions or well-known global objects (like $) as well.
contra 自定义方法是可枚举的。
pro 是的，但有 hasOwnProperty 来救援。将其包装在您自己的枚举器函数中，并停止使用带有对象的原始 for..in 循环。
contra Custom methods are enumerable.
pro Yes, but there's hasOwnProperty to the rescue. Wrap it in your own enumerator function and stop using raw for..in loops with objects.
（不是真正的答案，因此CW）
(not a real answer, hence CW)
这篇关于原生原型与$ .extension（）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
