Считается ли «новое» ключевое слово JavaScript вредным? [закрыто]

В другом вопросе пользователь указал, что newключевое слово опасно для использования, и предложил решение для создания объекта, которое не использовалось new. Я не верил, что это правда, в основном потому, что я использовал Prototype, Scriptaculous и другие прекрасные библиотеки JavaScript, и все использовали newключевое слово.

Несмотря на это, вчера я смотрел выступление Дугласа Крокфорда в театре YUI, и он сказал то же самое, что он больше не использовал newключевое слово в своем коде ( Крокфорд на JavaScript - Акт III: Функция Предельного - 50:23 минут ).

Это «плохо» использовать newключевое слово? Каковы преимущества и недостатки его использования?

Крокфорд много сделал для популяризации хороших методов JavaScript. Его самоуверенная позиция по ключевым элементам языка вызвала много полезных дискуссий. Тем не менее, есть слишком много людей, которые воспринимают каждое провозглашение «плохого» или «вредного» как Евангелие, отказываясь выходить за пределы мнения одного человека. Это может быть немного расстраивающим время от времени.

Использование функциональности, предоставляемой newключевым словом, имеет несколько преимуществ по сравнению с созданием каждого объекта с нуля:

1. Наследование прототипа . Несмотря на то, что те, кто привык к ОО-языкам на основе классов, часто воспринимаются со смесью подозрений и насмешек, родная технология наследования JavaScript является простым и удивительно эффективным средством повторного использования кода. И новое ключевое слово является каноническим (и только доступным кроссплатформенным) средством его использования.
2. Представление. Это побочный эффект # 1: если я хочу добавить 10 методов к каждому объекту, который я создаю, я мог бы просто написать функцию создания, которая вручную назначает каждый метод каждому новому объекту ... Или я мог бы назначить их создание функций prototypeи использование newдля удаления новых объектов. Это не только быстрее (код не требуется для каждого метода в прототипе), но и позволяет избежать раздувания каждого объекта с отдельными свойствами для каждого метода. На медленных машинах (или особенно медленных JS-интерпретаторах), когда создается много объектов, это может означать значительную экономию времени и памяти.

И да, newимеет один существенный недостаток, умело описанный другими ответами: если вы забудете его использовать, ваш код сломается без предупреждения. К счастью, этот недостаток легко устранить - просто добавьте немного кода в саму функцию:

function foo()
{
   // if user accidentally omits the new keyword, this will 
   // silently correct the problem...
   if ( !(this instanceof foo) )
      return new foo();

   // constructor logic follows...
}

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

if ( !(this instanceof arguments.callee) ) 
   throw new Error("Constructor called as a function");

(Обратите внимание, что этот фрагмент позволяет избежать жесткого кодирования имени функции конструктора, так как в отличие от предыдущего примера он не нуждается в создании экземпляра объекта - следовательно, он может быть скопирован в каждую целевую функцию без изменения.)

Джон Резиг подробно описывает эту технику в своем посте «Простое создание класса» , а также о том, как по умолчанию включить это поведение в ваши «классы». Определенно стоит читать ... как его предстоящая книга Секреты JavaScript Ninja , который находит скрытые золота в этом и многих других «вредных» особенности языка JavaScript ( раздел на withспециально просветить для тех из нас , кто первоначально отклонил это очень клеветническая особенность как уловка).

Я только что прочитал некоторые части его книги Крокфордса "Javascript: The Good Parts". У меня такое ощущение, что он считает все, что когда-либо укусило его, вредным:

О переключателе провалиться:

Я никогда не позволяю случаям переключения переходить к следующему случаю. Однажды я обнаружил в своем коде ошибку, вызванную непреднамеренным провалом сразу же после энергичной речи о том, почему провал иногда был полезен. (стр. 97, ISBN 978-0-596-51774-8)

О ++ и -

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

О новом:

Если вы забудете включить новый префикс при вызове функции конструктора, то это не будет связано с новым объектом. К сожалению, это будет привязано к глобальному объекту, поэтому вместо расширения вашего нового объекта вы будете блокировать глобальные переменные. Это действительно плохо. Нет предупреждения компиляции и предупреждения во время выполнения. (страница 49)

Есть еще, но я надеюсь, что вы получите картину.

Мой ответ на ваш вопрос: нет, это не вредно. но если вы забудете использовать его, когда у вас возникнут проблемы, у вас могут возникнуть проблемы. Если вы развиваетесь в хорошей среде, вы это замечаете.

Обновить

Примерно через год после написания этого ответа была выпущена пятая редакция ECMAScript с поддержкой строгого режима . В строгом режиме thisбольше не привязан к глобальному объекту, а к undefined.

Javascript - это динамический язык, и существует множество способов запутаться, когда другой язык остановит вас.

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

Я использую соглашение, в котором имена функций начинаются со строчной буквы, а «функции», которые на самом деле являются определениями классов, начинаются с заглавной буквы. Результатом является действительно весьма убедительный визуальный признак того, что «синтаксис» неверен:

var o = MyClass();  // this is clearly wrong.

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

var o = chair() // Executing chair is daft.
var o = createChair() // makes sense.

Интересно, как раскраска синтаксиса SO интерпретировала код выше.

Я новичок в Javascript, так что, возможно, я не слишком опытен в предоставлении хорошей точки зрения на это. И все же я хочу поделиться своим взглядом на эту «новую» вещь.

Я пришел из мира C #, где использование ключевого слова «new» настолько естественно, что мне кажется странным, что это шаблон фабричного дизайна.

Когда я впервые пишу код в Javascript, я не понимаю, что есть «новое» ключевое слово и код, подобный коду в шаблоне YUI, и мне не понадобится много времени, чтобы столкнуться с катастрофой. Я теряю представление о том, что должна делать конкретная строка при просмотре кода, который я написал. Более хаотичным является то, что мой разум не может действительно переходить между границами экземпляров объектов, когда я «пробую» код.

Затем я нашел «новое» ключевое слово, которое для меня это «отдельные» вещи. С новым ключевым словом он создает вещи. Без нового ключевого слова, я знаю, я не буду путать его с созданием вещей, если функция, которую я вызываю, не дает мне ясного представления об этом.

Например, у var bar=foo();меня нет никаких подсказок о том, какой бар может быть ... Это возвращаемое значение или это вновь созданный объект? Но var bar = new foo();я точно знаю, что бар - это объект.

Другой случай для нового - это то, что я называю Pooh Coding . Винни-Пух следует за своим животиком. Я говорю иди с языком, который ты используешь, а не против него.

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

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

РЕДАКТИРОВАТЬ: И это выходит далеко за рамки производительности. Я не могу сосчитать раз я слышал (или сказал) : «Почему, черт возьми , они делали что ?» при поиске странно выглядящего кода. Часто оказывается, что в то время, когда код был написан, для этого была какая-то «хорошая» причина. Следование Дао языка - ваша лучшая гарантия того, что ваш код не будет высмеян через несколько лет.

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

http://js-bits.blogspot.com/2010/08/constructors-without-using-new.html

Вот суть техники:

/**
 * Wraps the passed in constructor so it works with
 * or without the new keyword
 * @param {Function} realCtor The constructor function.
 *    Note that this is going to be wrapped
 *    and should not be used directly 
 */
function ctor(realCtor){
  // This is going to be the actual constructor
  return function wrapperCtor(){
    var obj; // object that will be created
    if (this instanceof wrapperCtor) {
      // Called with new
      obj = this;
    } else {
      // Called without new. Create an empty object of the
      // correct type without running that constructor
      surrogateCtor.prototype = wrapperCtor.prototype;
      obj = new surrogateCtor();
    }
    // Call the real constructor function
    realCtor.apply(obj, arguments);
    return obj;
  }

  function surrogateCtor() {}
}

Вот как это использовать:

// Create our point constructor
Point = ctor(function(x,y){
  this.x = x;
  this.y = y;
});

// This is good
var pt = new Point(20,30);
// This is OK also
var pt2 = Point(20,30);

Причина, по которой не используется ключевое слово new, проста:

Не используя его вообще, вы избегаете ловушки, которая возникает из-за случайного его пропуска. Шаблон построения, который использует YUI, является примером того, как можно полностью избежать нового ключевого слова "

var foo = function () {
    var pub= { };
    return pub;
}
var bar = foo();

В качестве альтернативы вы могли бы так это:

function foo() { }
var bar = new foo();

Но при этом вы рискуете, если кто-то забудет использовать ключевое слово new , а оператор this - fubar. AFAIK нет никакого преимущества для этого (кроме того, что вы привыкли к этому).

В конце дня: речь идет о защите. Можете ли вы использовать новое утверждение? Да. Это делает ваш код более опасным? Да.

Если вы когда-либо писали на C ++, это похоже на установку указателей на NULL после их удаления.

Я думаю, что «новый» добавляет ясности в код. И ясность стоит всего. Приятно знать, что есть подводные камни, но избегать их, избегая ясности, не кажется мне подходящим.

Случай 1: newне требуется и его следует избегать

var str = new String('asd');  // type: object
var str = String('asd');      // type: string

var num = new Number(12);     // type: object
var num = Number(12);         // type: number

Случай 2: newобязательно, в противном случае вы получите ошибку

new Date().getFullYear();     // correct, returns the current year, i.e. 2010
Date().getFullYear();         // invalid, returns an error

Вот краткое изложение двух самых сильных аргументов за и против использования new оператора:

Аргумент против new

1. Функции, предназначенные для реализации в виде объектов с использованием new оператора, могут иметь катастрофические последствия, если они неправильно вызываются как обычные функции. Код функции в таком случае будет выполняться в области, где вызывается функция, а не в области локального объекта, как предполагалось. Это может привести к тому, что глобальные переменные и свойства будут перезаписаны с катастрофическими последствиями.
2. Наконец, написание function Func(), а затем вызов Func.prototype и добавление к нему материала, чтобы можно было вызывать new Func()для создания объекта, кажется некрасивым некоторым программистам, которые предпочитают использовать другой стиль наследования объектов по архитектурным и стилистическим причинам.

Более подробно об этом аргументе можно прочитать в замечательной и лаконичной книге Дугласа Крокфорда «Javascript: The Good Parts». На самом деле проверить это в любом случае.

Аргумент в пользу new

1. Использование newоператора вместе с назначением прототипа быстро.
2. Эту штуку о случайном запуске кода функции конструктора в глобальном пространстве имен можно легко предотвратить, если вы всегда включаете в свои функции конструктора немного кода, чтобы проверить, правильно ли они вызываются, и, в случаях, когда они не вызываются , обрабатывая вызов соответствующим образом, как требуется.

См . Пост Джона Резига для простого объяснения этой техники и для более глубокого объяснения модели наследования, которую он защищает.

Я согласен с Pez и некоторые здесь.

Мне кажется очевидным, что «новое» - это самоописательное создание объекта, где шаблон YUI, описанный Грегом Дином, полностью скрыт .

Возможность того, что кто-то может написать var bar = foo;или var bar = baz();где baz не является методом создания объекта, кажется гораздо более опасной.

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

JavaScript основан на прототипах объектно-ориентированных. Следовательно, каждый объект ДОЛЖЕН быть создан из другого объекта var newObj=Object.create(oldObj). Здесь oldObj называется прототипом newObj (следовательно, «на основе прототипа»). Это означает, что если свойство не найдено в newObj, то оно будет найдено в oldObj . Таким образом, по умолчанию newObj будет пустым объектом, но из-за цепочки прототипов он, похоже, имеет все значения oldObj .

С другой стороны, если вы это сделаете var newObj=new oldObj(), прототип newObj это oldObj.prototype , который излишне сложен для понимания.

Хитрость заключается в использовании

Object.create=function(proto){
  var F = function(){};
  F.prototype = proto;
  var instance = new F();
  return instance;
};

Именно внутри этой функции и только здесь должно использоваться новое. После этого просто используйте метод Object.create () . Способ решает проблему прототипа.