foxxtrot e annakata sono entrambi corretti, ma mi butto i miei 2 centesimi.
Se si utilizza il prototipo, ciascuna istanza di "MessageClass" fa realmente riferimento alle stesse funzioni. Le funzioni esistono in memoria solo una volta e sono utilizzate per tutte le istanze. Se si dichiarano i metodi nel costruttore (o in altro modo lo si aggiunge a un'istanza specifica) anziché il prototipo, viene creata una nuova funzione per ogni istanza di MessageClass.
Detto questo, non c'è probabilmente alcuna differenza di prestazioni notevole nella maggior parte dei casi ed è improbabile che si notino anche differenze di utilizzo della memoria. Vorrei andare con il metodo prototipo a meno che non si abbia una ragione convincente per fare diversamente. L'unica ragione per cui posso dichiarare un metodo nel costruttore è se hai bisogno di una chiusura. Ad esempio, se si dispone di gestori di eventi o si voleva simulare le proprietà private con getter/setter si potrebbe fare:
function MessageClass() {
var self = this;
this.clickHander = function(e) { self.someoneClickedMe = true; };
var _private = 0;
this.getPrivate = function() { return _private; };
this.setPrivate = function(val) { _private = val; };
}
EDIT: perché non c'è stata discussione su come questi effetti oggetti estesi da un altro oggetto con funzioni assegnato nel costruttore sto aggiungendo un po 'più di dettaglio. Potrei usare il termine "classe" per semplificare la discussione, ma è importante notare che js non supporta le classi (ciò non significa che non possiamo fare un buon sviluppo OO) o non discuteremo di questo problema.
La maggior parte delle librerie javascript chiama il costruttore sulla classe base e sulla sottoclasse. (ad esempio, Object.extend di Prototype.js) Ciò significa che i metodi assegnati nel costruttore di ciascuno saranno disponibili sugli oggetti risultanti. Tuttavia, se stai estendendo gli oggetti da solo, possono esserci conseguenze inaspettate.
Se prendo le MessageClass sopra ed estenderlo:
function ErrorMessageClass() {}
ErrorMessageClass.prototype = new MessageClass();
errorMsg = new ErrorMessageClass();
Poi errorMsg avrà un getPrivate e il metodo setPrivate su di esso, ma non possono comportarsi come ci si aspetterebbe. Poiché tali funzioni erano a livello di ambito quando venivano assegnate (ad esempio in "ErrorMessageClass.prototype = new MessageClass()" non solo i metodi get/setPrivate sono condivisi, anche la variabile _private viene condivisa tra tutte le istanze di ErrorMessageClass. proprietà statica per ErrorMessageClass.Ad esempio:
var errorA = new ErrorMessageClass();
var errorB = new ErrorMessageClass();
errorA.setPrivate('A');
console.log(errorA.getPrivate()); // prints 'A'
console.log(errorB.getPrivate()); // prints 'A'
errorB.setPrivate('B');
console.log(errorA.getPrivate()); // prints 'B'
Allo stesso modo con la funzione clickHandler e someoneClickedMe proprietà:
errorA.clickHandler();
console.log(errorA.someoneClickedMe); // prints 'true'
console.log(errorB.someoneClickedMe); // prints 'true'
Tuttavia, modificare tali definizioni di funzioni da utilizzare this._private:
this.getPrivate = function() { return this._private; };
this.setPrivate = function(val) { this._private = val; };
e comportamento di istanze ErrorMessageClass diventa più di quello che ti aspetteresti:
errorA.setPrivate('A');
errorB.setPrivate('B');
console.log(errorA.getPrivate()); // prints 'A'
console.log(errorB.getPrivate()); // prints 'B'
accidenti a te per la tua eloquenza :) (anche se non sono d'accordo non c'è una differenza evidente) – annakata
Anche se si usa this._private, la variabile è accessibile dall'esterno. – Chris
(tecnicamente parlando, è possibile rintracciare un debugger in un modo o nell'altro, se non tutti, ambienti JS) – Chris