Когда я должен использовать свое собственное пространство имен и когда я должен расширять нативные объекты js? - PullRequest
Новая
       28

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

9 голосов
/ 28 декабря 2010

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

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

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

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. Как узнать, когда утилита лучше находиться в моем собственном пространстве имен?

Ответы [ 5 ]

7 голосов
/ 28 декабря 2010

  1. Почти никогда, из-за:

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

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

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

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

4 голосов
/ 28 декабря 2010

Смотрите это видео:

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

2 голосов
/ 28 декабря 2010

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

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

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

1 голос
/ 28 декабря 2010

Хорошо ... я не эксперт в этом, но почти никогда!Вещи, которые вы делаете, безопаснее в вашем пространстве имен.И все работает нормально, если вы следуете шаблону модуля 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 || {};
0 голосов
/ 28 декабря 2010

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

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

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

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

...