La "nuova" parola chiave di JavaScript è considerata dannosa? [chiuso]

In un'altra domanda , un utente ha sottolineato che la newparola chiave era pericolosa da usare e ha proposto una soluzione per la creazione di oggetti che non utilizzava new. Non credevo fosse vero, soprattutto perché ho usato Prototype, Scriptaculous e altre eccellenti librerie JavaScript, e tutti usavano la newparola chiave.

Nonostante ciò, ieri stavo guardando il discorso di Douglas Crockford al YUI Theater e ha detto esattamente la stessa cosa, che non ha più usato la newparola chiave nel suo codice ( Crockford su JavaScript - Act III: Function the Ultimate - 50:23 minuti ).

È "cattivo" usare la newparola chiave? Quali sono i vantaggi e gli svantaggi dell'utilizzo?

Crockford ha fatto molto per diffondere buone tecniche JavaScript. La sua posizione supponente su elementi chiave della lingua ha scatenato molte discussioni utili. Detto questo, ci sono troppe persone che prendono ogni annuncio di "cattivo" o "dannoso" come vangelo, rifiutando di guardare oltre l'opinione di un uomo. A volte può essere un po 'frustrante.

L'uso della funzionalità fornita dalla newparola chiave presenta diversi vantaggi rispetto alla creazione di ogni oggetto da zero:

1. Eredità del prototipo . Sebbene sia spesso considerata con un mix di sospetto e derisione da parte di coloro che sono abituati ai linguaggi OO di classe, la tecnica di ereditarietà nativa di JavaScript è un mezzo semplice e sorprendentemente efficace di riutilizzo del codice. E la nuova parola chiave è il mezzo canonico (e disponibile solo multipiattaforma) per usarlo.
2. Prestazione. Questo è un effetto collaterale del n. 1: se voglio aggiungere 10 metodi a ogni oggetto che creo, potrei semplicemente scrivere una funzione di creazione che assegni manualmente ogni metodo a ciascun nuovo oggetto ... Oppure, potrei assegnarli al funzione di creazione prototypee uso newper sradicare nuovi oggetti. Non solo è più veloce (non è necessario alcun codice per ogni singolo metodo sul prototipo), ma evita il palloncino di ogni oggetto con proprietà separate per ciascun metodo. Su macchine più lente (o in particolare su interpreti JS più lenti) quando vengono creati molti oggetti, ciò può significare un notevole risparmio di tempo e memoria.

E sì, newha uno svantaggio cruciale, abilmente descritto da altre risposte: se dimentichi di usarlo, il tuo codice si romperà senza preavviso. Fortunatamente, questo svantaggio è facilmente mitigato: basta aggiungere un po 'di codice alla funzione stessa:

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...
}

Ora puoi avere i vantaggi di newsenza doverti preoccupare dei problemi causati da un uso improprio accidentale. Potresti anche aggiungere un'asserzione al controllo se il pensiero di un codice non funzionante silenziosamente ti disturba. Oppure, come alcuni hanno commentato, utilizzare il segno di spunta per introdurre un'eccezione di runtime:

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

(Si noti che questo frammento è in grado di evitare di codificare il nome della funzione di costruzione in quanto, diversamente dall'esempio precedente, non è necessario istanziare effettivamente l'oggetto, pertanto può essere copiato in ciascuna funzione di destinazione senza modifiche.)

John Resig approfondisce questa tecnica nel suo semplice post sull'istanza "Class" , oltre a includere un mezzo per incorporare questo comportamento nelle "classi" per impostazione predefinita. Sicuramente merita una lettura ... come lo è il suo prossimo libro, Secrets of the JavaScript Ninja , che trova l'oro nascosto in questa e molte altre caratteristiche "dannose" del linguaggio JavaScript (il capitolo su withè particolarmente illuminante per quelli di noi che inizialmente hanno respinto questa caratteristica molto diffamata come un espediente).

Ho appena letto alcune parti del suo libro di Crockfords "Javascript: The Good Parts". Ho la sensazione che consideri dannoso tutto ciò che lo ha mai morso:

Informazioni su switch fall through:

Non permetto mai che i casi di commutazione passino al caso successivo. Una volta ho trovato un bug nel mio codice causato da una caduta involontaria subito dopo aver fatto un discorso vigoroso sul perché la caduta attraverso a volte era utile. (pagina 97, ISBN 978-0-596-51774-8)

Informazioni su ++ e -

È noto che gli operatori ++ (incremento) e - (decremento) contribuiscono al cattivo codice incoraggiando l'eccessiva inganno. Sono secondi solo all'architettura difettosa nel consentire virus e altre minacce alla sicurezza. (pagina 122)

A proposito di nuovi:

Se si dimentica di includere il nuovo prefisso quando si chiama una funzione di costruzione, questo non sarà associato al nuovo oggetto. Purtroppo, questo sarà legato all'oggetto globale, quindi invece di aumentare il tuo nuovo oggetto, intaserai le variabili globali. È davvero brutto. Non esiste alcun avviso di compilazione e non esiste alcun avviso di runtime. (pagina 49)

Ce ne sono altri, ma spero che tu possa ottenere l'immagine.

La mia risposta alla tua domanda: No, non è dannoso. ma se dimentichi di usarlo quando dovresti potresti avere dei problemi. Se stai sviluppando in un buon ambiente, lo noti.

Aggiornare

Circa un anno dopo la stesura di questa risposta è stata rilasciata la quinta edizione di ECMAScript, con supporto per la modalità rigorosa . In modalità rigorosa, thisnon è più associato all'oggetto globale ma a undefined.

Javascript è un linguaggio dinamico e ci sono molti modi per rovinare dove un'altra lingua ti fermerebbe.

Evitare una caratteristica del linguaggio fondamentale come quella newsulla base del fatto che potresti incasinare è un po 'come rimuovere le tue nuove scarpe lucide prima di camminare attraverso un campo minato nel caso in cui potresti sporcarle.

Uso una convenzione in cui i nomi delle funzioni iniziano con una lettera minuscola e le "funzioni" che in realtà sono definizioni di classe iniziano con una lettera maiuscola. Il risultato è un indizio visivo abbastanza convincente che la "sintassi" è sbagliata:

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

Oltre a queste buone abitudini di denominazione aiutano. Dopo che tutte le funzioni fanno le cose e quindi dovrebbe esserci un verbo nel suo nome mentre le classi rappresentano oggetti e sono sostantivi e aggettivi senza verbo.

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

È interessante il modo in cui la colorazione della sintassi di SO ha interpretato il codice sopra.

Sono un principiante di Javascript, quindi forse non sono troppo esperto nel fornire un buon punto di vista a questo. Eppure voglio condividere la mia opinione su questa "nuova" cosa.

Vengo dal mondo C # in cui l'uso della parola chiave "nuovo" è così naturale che è il modello di design di fabbrica che mi sembra strano.

Quando scrivo per la prima volta il codice in Javascript, non mi rendo conto che ci sono la "nuova" parola chiave e il codice come quello nel modello YUI e non mi ci vuole molto a correre in un disastro. Perdo traccia di ciò che una determinata riga dovrebbe fare quando guardo indietro al codice che ho scritto. Più caotico è che la mia mente non può davvero transitare tra i confini delle istanze di oggetto quando sto "eseguendo il dry-run" del codice.

Poi, ho trovato la "nuova" parola chiave che per me "separava" le cose. Con la nuova parola chiave, crea cose. Senza la nuova parola chiave, so che non la confonderò con la creazione di cose a meno che la funzione che sto invocando non mi dia forti indizi.

Ad esempio, con var bar=foo();non ho idea di quale barra potrebbe essere ... È un valore di ritorno o è un oggetto appena creato? Ma con var bar = new foo();lo so per certo che la barra è un oggetto.

Un altro caso per il nuovo è quello che io chiamo Pooh Coding . Winnie the Pooh segue la sua pancia. Dico di andare con la lingua che stai usando, non contro di essa.

È probabile che i manutentori della lingua ottimizzeranno la lingua per gli idiomi che cercano di incoraggiare. Se inseriscono una nuova parola chiave nella lingua probabilmente pensano che abbia senso essere chiari quando si crea una nuova istanza.

Il codice scritto seguendo le intenzioni della lingua aumenterà in efficienza con ogni versione. E il codice che evita i costrutti chiave della lingua soffrirà col tempo.

EDIT: E questo va ben oltre le prestazioni. Non riesco a contare le volte che ho sentito (o detto) "perché diavolo hanno fatto quello ?" quando si trova un codice dall'aspetto strano. Si scopre spesso che al momento della stesura del codice c'era una "buona" ragione per questo. Seguire il Tao della lingua è la tua migliore assicurazione per non avere il tuo codice ridicolizzato tra qualche anno.

Ho scritto un post su come mitigare il problema di chiamare un costruttore senza la nuova parola chiave.
È principalmente didattico, ma mostra come è possibile creare costruttori che funzionano con o senza newe non richiedono l'aggiunta di codice boilerplate per testare thisin ogni costruttore.

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

Ecco l'essenza della tecnica:

/**
 * 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() {}
}

Ecco come usarlo:

// 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);

La logica alla base del mancato utilizzo della nuova parola chiave è semplice:

Non utilizzandolo affatto, si evita la trappola che si manifesta con l'omissione accidentale. Il modello di costruzione utilizzato da YUI è un esempio di come è possibile evitare del tutto la nuova parola chiave "

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

In alternativa potresti farlo così:

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

Ma così facendo corri il rischio che qualcuno si dimentichi di usare la nuova parola chiave e che questo operatore sia completamente fubar. AFAIK non ha alcun vantaggio nel fare questo (a parte quello a cui sei abituato).

Alla fine del giorno: si tratta di essere sulla difensiva. Puoi usare la nuova dichiarazione? Sì. Rende il tuo codice più pericoloso? Sì.

Se hai mai scritto C ++, è come impostare i puntatori su NULL dopo averli eliminati.

Penso che "nuovo" aggiunga chiarezza al codice. E la chiarezza vale tutto. Buono a sapersi che ci sono insidie, ma evitarle evitando la chiarezza non mi sembra la strada giusta.

Caso 1: newnon è richiesto e dovrebbe essere evitato

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

Caso 2: newè obbligatorio, altrimenti verrà visualizzato un errore

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

Ecco il sommario più breve che potrei fare dei due argomenti più forti a favore e contro l'uso newdell'operatore:

Discussione contro new

1. Le funzioni progettate per essere istanziate come oggetti mediante l' newoperatore possono avere effetti disastrosi se vengono invocate in modo errato come normali funzioni. Il codice di una funzione in tal caso verrà eseguito nell'ambito in cui viene chiamata la funzione, anziché nell'ambito di un oggetto locale come previsto. Ciò può causare la sovrascrittura di variabili e proprietà globali con conseguenze disastrose.
2. Infine, scrivere function Func(), quindi chiamare Func.prototype e aggiungere elementi in modo da poter chiamare new Func()per costruire il tuo oggetto sembra brutto per alcuni programmatori, che preferiscono utilizzare un altro stile di eredità dell'oggetto per motivi architettonici e stilistici.

Per ulteriori informazioni su questo argomento, consulta il fantastico e conciso libro di Douglas Crockford, Javascript: The Good Parts. In effetti, controlla comunque.

Argomento a favore di new

1. L'uso newdell'operatore insieme all'assegnazione dei prototipi è rapido.
2. Quelle cose sull'esecuzione accidentale del codice di una funzione di costruzione nello spazio dei nomi globale possono essere facilmente evitate se si include sempre un po 'di codice nelle funzioni di costruzione per verificare se vengono chiamate correttamente e, nei casi in cui non lo sono , gestendo la chiamata in modo appropriato come desiderato.

Vedi il post di John Resig per una semplice spiegazione di questa tecnica e per una spiegazione generalmente più profonda del modello di eredità che sostiene.

Sono d'accordo con Pez e alcuni qui.

Mi sembra ovvio che "nuovo" sia la creazione di oggetti auto-descrittivi, in cui il modello YUI descritto da Greg Dean è completamente oscurato .

La possibilità che qualcuno possa scrivere var bar = foo;o var bar = baz();dove baz non è un metodo di creazione di oggetti sembra molto più pericolosa.

Penso che il nuovo sia malvagio, non perché se si dimentica di usarlo per errore potrebbe causare problemi, ma perché rovina la catena ereditaria, rendendo il linguaggio più difficile da capire.

JavaScript è orientato agli oggetti basato su prototipo. Quindi ogni oggetto DEVE essere creato da un altro oggetto in questo modo var newObj=Object.create(oldObj). Qui oldObj è chiamato il prototipo di newObj (quindi "basato sul prototipo"). Ciò implica che se una proprietà non viene trovata in newObj , verrà cercata in oldObj . newObj di default sarà quindi un oggetto vuoto ma a causa della sua catena di prototipi sembra avere tutti i valori di oldObj .

D'altra parte, se lo fai var newObj=new oldObj(), il prototipo di newObj è oldObj.prototype , che è inutilmente difficile da capire.

Il trucco è usare

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

È all'interno di questa funzione e solo qui dovrebbe essere usato il nuovo. Dopodiché usa semplicemente il metodo Object.create () . Il metodo risolve il problema del prototipo.