Родные прототипы против $.extension()

На работе мы используем jQuery. Вскоре после того, как мы начали использовать его, я увидел, что несколько разработчиков добавили функции в файл jquery-extensions.js. Внутри я нашел целую кучу методов, добавленных в $, которые по существу представляют собой статические методы в jQuery. Вот несколько:

$.formatString(str, args) {
    ...
}

$.objectToArray(obj) {
    ...
}

Etc. Ни один из них не использует ничего общего с jQuery. Это показалось мне странным.

В конце концов нам понадобилась функция в нашей библиотеке для локализации дат. Моим решением было создать:

Date.prototype.toLocaleDate = function() {
    ...
}

Date.parseLocalDate = function() {
   ...
}

Вскоре после этого я заставлю старшего разработчика, спрашивающего меня, что я думаю, что я делаю. Он говорит мне, что здесь, где я работаю, мы не создаем прототипы, потому что они злые. Единственными причинами, которые он дал, было то, что они в основном являются плохими языковыми особенностями, потому что их "можно злоупотреблять" и что это путано, чтобы увидеть прототипы (например, как я могу узнать новую дату(). ToLocaleDate() является прототипом, а не родным ECMAScript). Используя $.formatString(...) вместо "blah blah".formatString(...), мы ясно говорим, что все, что имеет значение $, не является частью собственного JavaScript.

Эти причины кажутся немного глупыми, но я предложил компромисс, поэтому ему не нужно было бы помнить, был ли метод прототипом: префикс имени функции прототипа с помощью $:

String.prototype.$format = function() {
    ...
}

"blah blah".$format(...);

Это было быстро отклонено, и теперь мне нужно добавлять эти функции $.myPrototypeAsAFauxStaticMethodOnjQuery() всюду.

Я единственный, кто считает, что эта практика глупа?

Ответы

Ответ 1

Обсуждение родных прототипов немного устало, есть правильные точки с обеих сторон, я постараюсь их обобщить в надежде, что было бы полезно увидеть большую картину.

contra Не нужно расширять собственные прототипы. У вас есть все, что вам нужно.
pro Стандартная библиотека JS до предела ограничена. Массивов и строк не хватает многих жизненно важных функций.

contra Используйте функции или свои собственные пространства имен.
pro. Методы, подобные foo.trim(), гораздо больше соответствуют духу языка, чем функции, такие как org.blah.trim(foo). Все это объект в javascript, и пусть это будет так.

contra Собственные объекты JS зарезервированы для разработчиков языка. Наши методы могут случайно переопределить недавно добавленные встроенные модули.
pro Открытые объекты - отличная функция, и было бы глупо не использовать ее. Новая версия Javascript не является чем-то, что происходит каждый день, и дополнения к стандарту хорошо известны заранее.

contra Расширение собственных прототипов запутывает, потому что нет никакого различия между нашими и собственными методами.
pro Стандартная библиотека JS небольшая и хорошо документирована. Мы, разработчики javascript, должны знать имена собственных методов.

contra Расширение прототипов может привести к конфликтам пространства имен.
pro Да, но это может произойти с глобальными функциями или общеизвестными глобальными объектами (например, $).

contra Пользовательские методы перечислены.
pro Да, но там hasOwnProperty на помощь. Оберните его в свою собственную функцию перечислителя и прекратите использовать необработанные циклы for..in с объектами.

(не реальный ответ, следовательно, CW)

Ответ 2

  • Старшие заголовки часто переоцениваются.
  • Есть много людей, которые не понимают прототипного наследования.
  • Несмотря на то, что расширение прототипа собственных объектов JavaScript является законным, не делайте этого. Вы рискуете столкнуться с фреймворками.
  • Не имеет смысла перехватывать $ для не-jQuery служебных функций. Почему бы не использовать собственное пространство имен компании? Если вам нужно быть кратким, используйте $$ и т.д.

Ответ 3

Я думаю, что это не глупо!, Но это красивее использовать прототип!, Но опять же кто заботится о красоте? Ваш код в конечном итоге будет страшен, и будет сосать, но если он хорошо документирован и согласован, вам никогда не придется думать об этих проблемах!