$.formatString(str,args) {
...
}
$.objectToArray(obj) {
...
}
等等,他们实际上并没有使用jQuery做任何事情.这让我感到奇怪.
Date.prototype.toLocaleDate = function() {
...
}
Date.parseLocalDate = function() {
...
}
不久之后,我得到一名高级开发人员来问我,我想我在做什么.他告诉我,在这里,我在哪里工作,我们不会创造原型,因为它们是邪恶的.他所提供的唯一原因是他们从根本上讲是一种糟糕的语言特征,因为它们可以被滥用,并且看到原型令人困惑(例如我如何知道新的Date().LocaleDate()是一个原型而不是本机的ECMAScript ).通过使用$.formatString(…)而不是“blah blah”.formatString(…),我们保持清楚,任何带有$的东西都不是本机JavaScript的一部分.
这些原因似乎有点愚蠢,但是我提出了妥协,所以他不必记住一个方法是一个原型前缀的原型函数名称与$：
String.prototype.$format = function() {
...
}
"blah blah".$format(...);
这很快被解雇了,现在我不得不在任何地方添加这些$.myPrototypeAsAFauxStaticMethodOnjQuery()函数.
我唯一认为这种做法是愚蠢的吗？
解决方法
对比没有必要扩展原生的原型.你有你需要的一切
亲JS标准库极其稀缺.数组和字符串缺乏许多重要特征.
使用功能或您自己的“命名空间”.
pro像foo.trim()这样的方法比org.blah.trim(foo)等函数更符合语言的精神.一切都是javascript中的对象,让它成为一种方式.
对等本地JS对象是为语言设计者“保留”的.我们的方法可能会意外覆盖新增的内置功能.
pro打开对象是一个很大的功能,它将是愚蠢的不使用它.一个新的Javascript版本不是每天发生的事情,标准的增加是提前知道的.
对比扩展原生原型是令人困惑的,因为我们和本地方法之间没有区别.
pro JS标准库很小,文档很好.我们JavaScript开发人员应该知道本机方法的名称.
扩展原型可能导致命名空间冲突.
亲是的,但这可能发生在全球功能或众所周知的全球对象(如$)上.
自定义方法是可列举的.
亲是的,但是有一个呵呵的ProProtyty.将其包装在您自己的枚举器函数中,并停止使用带有对象的raw for..in循环.
(不是一个真正的答案,因此CW)
