Quando devo utilizzare il mio spazio dei nomi e quando devo estendere js nativi oggetti?

Question

Sono in fase di refactoring mio codice. Sto avendo difficoltà a decidere su come esattamente per implementare un paio di funzioni di utilità che ho. In particolare , se alcune funzioni sono meglio nel mio spazio dei nomi personali o js estendono oggetti direttamente.

Esempio di estendere nativo JavaScript Oggetti

(è questo il termine corretto?).

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

Esempio usando il mio spazio dei nomi

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

Domande da considerare

1. Quando viene un programma di utilità giustamente inserito in un oggetto nativo JavaScript?
2. Come faccio a dire quando un programma di utilità è meglio essere nel mio spazio dei nomi?

Answer 1

1. Quasi mai, a causa di:

   A / possibili conflitti con altre librerie

   b / funzioni estese sono iterati come proprietà di in operatore, che pone problemi a meno filtrati dal hasOwnProperty (che non è comunemente usato)

   Si può giustificare questo per piccoli lavori, una sceneggiatura, ma solo se si 200% sicuro che nessuno, mai e poi mai proverà a riutilizzare quel codice da qualche parte. In tal caso usarlo solo per la funzionalità, che si estende su più di un modulo di codice. Estendere String con finiture () - ok, estendendo String con prettyDate () - dubbioso, estendendo Oggetto con displayAsPageHeader () -. Spaventoso

2. Quindi, quasi sempre.

Answer 2

Vedere questo video:

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

calcola John Resig che l'estensione oggetti nativi è una ricetta per il disastro, in particolare quando un framework o applicazione è destinata a crescere in qualcosa che fa molto di più di quanto inizialmente previsto.

Answer 3

Purtroppo, questa domanda non ha una risposta "giusta". E 'una buona discussione per avere ma temo che sarà chiusa qui. Sia gli oggetti nativi dovrebbero essere estesi a tutti è un dibattito soggettiva, e se si accetta che è condizionato va bene la risposta alla domanda "quando?" è "dipende".

Se si dispone di controllo sul suo utilizzo e se si scontrerà con altro codice, non c'è davvero alcun motivo non si dovrebbe. Può essere molto conveniente e può ridurre in modo significativo le dimensioni del codice.

Dove c'è un problema reale con l'estensione oggetti nativi è quando si ha altro codice che costeggia proprio interno, che può essere in attesa di una diversa estensione con lo stesso nome della proprietà, o che possono essere incautamente utilizza for(var i in obj) senza la guardia contro le estensioni su per la prototipo catena.

Answer 4

Ok ... Io non sono esperto in questo, ma quasi mai! Le cose che si fanno sono più sicuri all'interno del vostro spazio dei nomi. E tutto funziona bene se si segue il modello del modulo http: // www. yuiblog.com/blog/2007/06/12/module-pattern/

Tuttavia theres sono alcuni piccoli trucchi che ci permette di evitare ad altri di sovrascrittura dello spazio dei nomi. per esempio:

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

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

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

Answer 5

Dipende da quanto controllo si hanno a disposizione ciò che il codice è in esecuzione / caricato:

1. Se è tutto sotto il vostro controllo non c'è niente di sbagliato con estende oggetti incorporati, JavaScript è stato progettato per essere in grado di fare questo. L'unico problema di questo è che si può avere problemi imprevisti quando due librerie cambiano la stessa cosa. Per fortuna che non si farebbe questo a te stesso, giusto?

2. Se non / non può conoscere, uno spazio dei nomi è molto più sicuro anche se goffo e prolisso. Questo è sempre più sicuro.

Personalmente, preferisco la seconda opzione, perché non mi piace eccessivamente prolisso codice e spazi dei nomi aspetto divertente.