foxxtrot y annakata son las dos correctas, pero arrojaré mis 2 centavos.
Si usa el prototipo, cada instancia de "MessageClass" hace referencia realmente a las mismas funciones. Las funciones existen en la memoria solo una vez y se usan para todas las instancias. Si declara los métodos en el constructor (o lo agrega a una instancia específica) en lugar del prototipo, se crea una nueva función para cada instancia de MessageClass.
Habiendo dicho esto, probablemente no haya ninguna diferencia de rendimiento notable para la mayoría de los casos y tampoco es probable que vea una diferencia en el uso de la memoria. Me gustaría ir con el método prototipo a menos que tengas una razón convincente para hacer lo contrario. La única razón por la que puedo pensar que es posible que desee declarar un método en el constructor es si necesita un cierre. Por ejemplo, si tiene controladores de eventos o que quería para simular las propiedades privadas con getters/setters que podría hacer:
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: Debido a que no ha habido un debate acerca de cómo esto afecta objetos extendidos por otro objeto con funciones asignado en el constructor, estoy agregando un poco más de detalle. Podría usar el término "clase" para simplificar la discusión, pero es importante tener en cuenta que js no admite clases (eso no significa que no podamos hacer un buen desarrollo OO) o no estaríamos discutiendo este tema.
La mayoría de las bibliotecas de javascript llaman al constructor en la clase base y la subclase. (por ejemplo, Object.extend de Prototype.js) Esto significa que los métodos asignados en el constructor de cada uno estarán disponibles en los objetos resultantes. Sin embargo, si extiende los objetos usted mismo, puede haber consecuencias inesperadas.
si tomo el MessageClass arriba y extenderla:
function ErrorMessageClass() {}
ErrorMessageClass.prototype = new MessageClass();
errorMsg = new ErrorMessageClass();
Entonces errorMsg tendrá un getPrivate y el método setPrivate en él, pero no se pueden comportar como era de esperar. Debido a que esas funciones tenían un alcance cuando se asignaron (es decir, en "ErrorMessageClass.prototype = new MessageClass()" no solo se comparten los métodos get/setPrivate, también se comparte la variable _private en todas las instancias de ErrorMessageClass. Esto esencialmente hace _private a propiedad estática para ErrorMessageClass.Por ejemplo:
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'
mismo modo con la función de clickHandler y someoneClickedMe propiedad:
errorA.clickHandler();
console.log(errorA.someoneClickedMe); // prints 'true'
console.log(errorB.someoneClickedMe); // prints 'true'
Sin embargo, cambiar esas definiciones de función para utilizar this._private:
this.getPrivate = function() { return this._private; };
this.setPrivate = function(val) { this._private = val; };
y el comportamiento de las instancias de ErrorMessageClass se vuelve más de lo que cabría esperar:
errorA.setPrivate('A');
errorB.setPrivate('B');
console.log(errorA.getPrivate()); // prints 'A'
console.log(errorB.getPrivate()); // prints 'B'
maldito por su elocuencia :) (aunque estoy en desacuerdo, no hay una diferencia notable) – annakata
Aunque si utiliza this._private, la variable es accesible desde el exterior. – Chris
(técnicamente hablando, puede rastrear con un depurador de cualquier manera en la mayoría de los entornos JS, si no en todos) – Chris