Как правильно расширить функционал стандартных объектов в js?

Question

[Kirill Popolov]

Хотелось бы добавить несколько методов для работы со строками и массивами. Не могу понять как лучше сделать:
* Через прототип (Array.prototype). Проще всего, но мне кажется это может вызвать конфликты в случае использования в чужом коде.
* Через дочерний объект (усложняет тем, что нужно каждый раз создавать инстанс нового объекта)
* Через простую функцию

Возможно есть еще способы? Какие плюсы и минусы у указанных способов?

Answer 1

[Назар Мокринский]

Третий непонятный, первый и второй - вполне себе варианты, если проигнорировать, что расширение стандартных объектов не рекомендуется.
С первым и правда могут возникнуть конфликты, плюс методы буду даже там, где вы их не используете. При правильном добавлении и уверенности что конфликтов не будет - можно пользоваться.
Во втором проще тем, что используется только там где нужно, не мешает никому, но вот удобство падает существенно.

Comments

[Kirill Popolov]

под третим я имел в виду, что не расширять объекты, а просто передавать в функцию входные данные и параметры, не заморачиваясь с объектами.

[Kirill Popolov]

либо, как подсказывают ниже, создать отдельный объект со своими методами, в которые уже передавать данные и параметры.

Answer 2

[Денис Пушкарев]

Ну а какие могут быть еще варианты? :)
По первому - если его использовать, то нужно убедиться, что заданный метод отсутствует в стандарте / хотя бы одной реализации. Если их аналоги присутствуют там - может лучше реализовать их? Расширять прототипы только используя defineProperty с enumerable: false, дабы не сломать for-in. Ну и не использовать никакие другие библиотеки, расширяющие build-in объекты, кроме полифилов.
Не устраивает - тогда второе или третье. Они легко совмещаются, см., например, как это реализовано в undescore.js

Comments

[Kirill Popolov]

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

[Денис Пушкарев]

@ezhikov я лично нестандартизованные методы переопределяю принудительно. Появится в стандарте / одном из движков метод, с тем же именем, что и в библиотеке - никакой старый код не поломает. А в следующей версии библиотеки никто не мешает его исправить на совместимый со стандартом. Тут главная опасность исходит от библиотек, также модифицирующих стандартные объекты. Так что вместе с подобным никаких sugar, mootols, prototype.js. Ну и главное - следить за планами расширения языка.

Answer 3

[Rrooom]

Лучше третий путь - подход undescore и lodash. Удобно, красиво, не может поломать внешние библиотеки.