Javascript cuando usar prototipos

Me gustaría entender cuándo es apropiado usar métodos de prototipo en js. ¿Deben usarse siempre? ¿O hay casos en los que su uso no es preferido y / o incurre en una penalización de rendimiento?

Al buscar en este sitio métodos comunes para el espacio de nombres en js, parece que la mayoría usa una implementación no basada en prototipos: simplemente usa un objeto o un objeto de función para encapsular un espacio de nombres.

Viniendo de un lenguaje basado en clases, es difícil no intentar establecer paralelismos y pensar que los prototipos son como "clases" y las implementaciones del espacio de nombres que mencioné son como métodos estáticos.

Los prototipos son una optimización .

Un gran ejemplo de cómo usarlos bien es la biblioteca jQuery. Cada vez que obtiene un objeto jQuery utilizando $('.someClass'), ese objeto tiene docenas de "métodos". La biblioteca podría lograr eso devolviendo un objeto:

return {
   show: function() { ... },
   hide: function() { ... },
   css: function() { ... },
   animate: function() { ... },
   // etc...
};

Pero eso significaría que cada objeto jQuery en la memoria tendría docenas de ranuras con nombre que contienen los mismos métodos, una y otra vez.

En cambio, esos métodos se definen en un prototipo y todos los objetos jQuery "heredan" ese prototipo para obtener todos esos métodos a un costo de ejecución muy bajo.

Una parte de vital importancia de cómo jQuery lo hace bien es que esto está oculto al programador. Se trata simplemente como una optimización, no como algo de lo que tenga que preocuparse cuando use la biblioteca.

El problema con JavaScript es que las funciones de constructor desnudas requieren que la persona que llama recuerde ponerles un prefijo newo, de lo contrario, normalmente no funcionan. No hay una buena razón para ello. jQuery lo hace bien al ocultar esas tonterías detrás de una función ordinaria $, por lo que no tiene que preocuparse de cómo se implementan los objetos.

Para que pueda crear cómodamente un objeto con un prototipo específico, ECMAScript 5 incluye una función estándar Object.create. Una versión muy simplificada se vería así:

Object.create = function(prototype) {
    var Type = function () {};
    Type.prototype = prototype;
    return new Type();
};

Simplemente se encarga del dolor de escribir una función constructora y luego llamarla con new .

¿Cuándo evitarías los prototipos?

Una comparación útil es con lenguajes de OO populares como Java y C #. Estos admiten dos tipos de herencia:

• interfaz de la herencia, en el que implementun interfacetal que la clase proporciona su propia implementación única para cada miembro de la interfaz.
• aplicación de herencia, en el que extenduna classque proporciona implementaciones por defecto de algunos métodos.

En JavaScript, la herencia prototípica es una especie de herencia de implementación . Entonces, en aquellas situaciones en las que (en C # o Java) habría derivado de una clase base para obtener el comportamiento predeterminado, al que luego realiza pequeñas modificaciones a través de anulaciones, luego en JavaScript, la herencia prototípica tiene sentido.

Sin embargo, si se encuentra en una situación en la que habría utilizado interfaces en C # o Java, entonces no necesita ninguna característica de lenguaje en particular en JavaScript. No es necesario declarar explícitamente algo que represente la interfaz, y no es necesario marcar los objetos como "implementando" esa interfaz:

var duck = {
    quack: function() { ... }
};

duck.quack(); // we're satisfied it's a duck!

En otras palabras, si cada "tipo" de objeto tiene sus propias definiciones de los "métodos", entonces no tiene ningún valor heredar de un prototipo. Después de eso, depende de cuántas instancias asigne de cada tipo. Pero en muchos diseños modulares, solo hay una instancia de un tipo determinado.

Y de hecho, muchas personas han sugerido que la herencia de implementación es mala . Es decir, si hay algunas operaciones comunes para un tipo, entonces tal vez sea más claro si no se colocan en una clase base / super, sino que se exponen como funciones ordinarias en algún módulo, al que se le pasa el objeto (s) desea que operen.

Debería utilizar prototipos si desea declarar un método "no estático" del objeto.

var myObject = function () {

};

myObject.prototype.getA = function (){
  alert("A");
};

myObject.getB = function (){
  alert("B");
};

myObject.getB();  // This works fine

myObject.getA();  // Error!

var myPrototypeCopy = new myObject();
myPrototypeCopy.getA();  // This works, too.

Una razón para usar el prototypeobjeto integrado es si va a duplicar un objeto varias veces que compartirá una funcionalidad común. Al adjuntar métodos al prototipo, puede ahorrar en la creación de métodos duplicados para cada newinstancia. Pero cuando adjunta un método al prototype, todas las instancias tendrán acceso a esos métodos.

Digamos que tiene una Car()clase / objeto base .

function Car() {
    // do some car stuff
}

luego crea varias Car()instancias.

var volvo = new Car(),
    saab = new Car();

Ahora, sabe que cada automóvil deberá conducir, encender, etc. En lugar de adjuntar un método directamente a la Car()clase (que ocupa memoria por cada instancia creada), puede adjuntar los métodos al prototipo (creando los métodos solo once), dando acceso a esos métodos tanto al nuevo volvocomo a saab.

// just mapping for less typing
Car.fn = Car.prototype;

Car.fn.drive = function () {
    console.log("they see me rollin'");
};
Car.fn.honk = function () {
    console.log("HONK!!!");
}

volvo.honk();
// => HONK!!!
saab.drive();
// => they see me rollin'

Coloque funciones en un objeto prototipo cuando vaya a crear muchas copias de un tipo particular de objeto y todas necesiten compartir comportamientos comunes. Al hacerlo, ahorrará algo de memoria al tener solo una copia de cada función, pero ese es solo el beneficio más simple.

Cambiar métodos en objetos prototipo, o agregar métodos, cambia instantáneamente la naturaleza de todas las instancias del tipo (s) correspondiente (s).

Ahora, exactamente por qué haría todas estas cosas es principalmente una función del diseño de su propia aplicación y el tipo de cosas que necesita hacer en el código del lado del cliente. (Una historia completamente diferente sería el código dentro de un servidor; mucho más fácil de imaginar haciendo más código "OO" a gran escala allí).

Si explico en el término basado en la clase, entonces Person es clase, walk () es el método Prototype. Así que walk () tendrá su existencia solo después de crear una instancia de un nuevo objeto con esto.

Entonces, si desea crear copias de objetos como Persona u, puede crear muchos usuarios. El prototipo es una buena solución, ya que ahorra memoria al compartir / heredar la misma copia de función para cada uno de los objetos en la memoria.

Mientras que la estática no es de gran ayuda en tal escenario.

function Person(){
this.name = "anonymous";
}

// its instance method and can access objects data data 
Person.prototype.walk = function(){
alert("person has started walking.");
}
// its like static method
Person.ProcessPerson = function(Person p){
alert("Persons name is = " + p.name);
}

var userOne = new Person();
var userTwo = new Person();

//Call instance methods
userOne.walk();

//Call static methods
Person.ProcessPerson(userTwo);

Entonces, con esto es más parecido al método de instancia. El enfoque del objeto es como los métodos estáticos.

https://developer.mozilla.org/en/Introduction_to_Object-Oriented_JavaScript