Когда мне следует использовать собственное пространство имен, а когда следует расширять собственные объекты js?

Question

Я занимаюсь рефакторингом своего кода.У меня возникли проблемы с принятием решения о том, как именно реализовать пару имеющихся у меня служебных функций. Конкретно, если определенные функции лучше использовать в моем личном пространстве имен или напрямую расширять объекты js.

Пример расширения собственных объектов JavaScript

(это правильный термин?).

String.prototype.prettyDate = function(){
  return (this.substr(5,2) + '/' + this.substr(8) + '/' + this.substr(0,4));
}
var myString = "2010-12-27";
//logs 12/27/2010
console.log(myString.prettyDate);

Пример использования моего собственного пространства имен

var myNamespace = (function(){
   var my = {};
   my.prettyDate = function ( dateStr ){
      return (dateStr.substr(5,2) + '/' + dateStr.substr(8) + '/' + dateStr.substr(0,4));
   }
return my;
}());
var pretifiedDate = myNamespace.prettyDate('2010-12-27');
//logs 12/27/2010
console.log(pretifiedDate);

Вопросы для рассмотрения

1. Когда утилита оправданно вставляется в собственный объект JavaScript?
2. Как я могу определить, когда утилите лучше находиться в моем собственном пространстве имен?

Answer 1

1. Практически никогда по причине:

   а/ возможные конфликты с другими библиотеками

   б/ расширенные функции повторяются как свойства с помощью в оператор, который создает проблемы, если не отфильтрован с помощью hasOwnProperty (который обычно не используется)

   Вы можете оправдать это небольшими работами с одним скриптом, но только если вы на 200% уверены, что никто и никогда не попытается где-либо повторно использовать этот код.В таком случае используйте его только для функций, охватывающих более одного модуля вашего кода.Расширение String с помощью функции Trim() — ок, расширение String с помощью PrettyDate() — сомнительно, расширение объекта с помощью displayAsPageHeader() — страшно.

2. Итак, почти всегда.

Answer 2

Посмотри это видео:

• http://ejohn.org/blog/building-a-javascript-library/

Джон Ресиг считает, что расширение нативных объектов — это верный путь к катастрофе, особенно когда фреймворк или приложение, скорее всего, перерастут во что-то, что сделает гораздо больше, чем изначально предполагалось.

Answer 3

К сожалению, этот вопрос не имеет «правильного» ответа.Это хорошая дискуссия, но боюсь, что на этом она закроется.Независимо от того, должны ли нативные объекты быть расширенными вообще, являются субъективными дебатами, и если вы признаете, что условно в порядке ответа на «Когда?» «зависит».

Если у вас есть контроль над его использованием и над тем, будет ли он конфликтовать с другим кодом, на самом деле нет причин, по которым вам этого не следует делать.Это может быть весьма удобно и позволяет значительно уменьшить размер кода.

Реальная проблема с расширением собственных объектов возникает, когда рядом с вашим расширением работает другой код, который может ожидать другого расширения с тем же именем свойства или который может небрежно использовать for(var i in obj) без защиты от расширения цепочки прототипов.

Answer 4

Хорошо...я не специалист в этом, но почти никогда!То, что вы делаете, безопаснее внутри вашего пространства имен.И все работает нормально, если следовать шаблону модуля http://www.yuiblog.com/blog/2007/06/12/module-pattern/

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

var myNamespace = {}; //my namespace, unsafely written

//Better solution
if(typeof myNamespace === 'undefined'){
    var myNamespace = {};
}

//Shorter solution
var myNamespace = myNamespace || {};

Answer 5

Это зависит от того, насколько вы контролируете, какой код запускается/загружается:

1. Если все под вашим контролем, то нет ничего плохого в расширении встроенных объектов, JavaScript предназначен для этого.Единственная проблема заключается в том, что могут возникнуть неожиданные проблемы, когда две библиотеки изменяют одно и то же.К счастью, вы бы не сделали этого с собой, верно?

2. Если вы не знаете/не можете знать, пространство имен гораздо безопаснее, хотя и неуклюжее и многословное.Это всегда безопаснее.

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