La programación OOP en JavaScript se puede hacer de muchas maneras. Hay muchos patrones alrededor.

Te mostraré dos, una implementación de herencia de objetos y una implementación de composición de objetos.

Esto no tiene absolutamente nada que ver con jQuery. jQuery debe usarse para la manipulación de DOM y la manipulación de eventos. No debe hacer que sus objetos y constructores principales se basen en objetos jQuery. En un juego, el rol de jQuery es leer la entrada del teclado y, opcionalmente, representar sus gráficos en el DOM (si no está usando el <canvas> por alguna razón).

ejemplo en vivo

Herencia

 var Constructor = function(name) { this.name = name }; Constructor.prototype.mymethod = function() { alert("my name is : " + this.name); }; var obj = new Constructor("foo"); obj.mymethod(); // my name is : foo

Aquí estamos definiendo una función Constructor a la que puede llamar para crear un nuevo objeto. Te refieres al objeto dentro del constructor con this .

Puede agregar métodos y variables (estáticos) al prototipo del Constructor que heredará el objeto.

 function inherits(child, parent) { var f = new Function; f.prototype = parent.prototype; f.prototype.constructor = parent; child.prototype = new f; child.prototype.constructor = child; }

Puede usar una función inherits que establece el prototipo de una función constructora en una instancia de un constructor diferente. Esto significa que todos los métodos y propiedades de ese objeto principal están disponibles en el objeto secundario.

 var SecondConstructor = function(name) { this.name = name + "bar"; }; inherits(SecondConstructor, Constructor); var obj = new SecondConstructor("foo"); obj.mymethod(); // my name is : foobar

Esta es la herencia prototípica de JavaScript. Básicamente, configura el prototipo de una función para un objeto en particular. Luego, cuando usa la función para crear objetos, esos objetos implementan el prototipo.

Composición

En realidad, no es necesario usar el prototipo, también puede usar la composición de objetos. Este método requiere una buena comprensión de this estado sobre el que puede leer en otros lugares .

Voy a hacer trampa y delegar algunas de las tediosas funciones auxiliares a underscore.js

 var Constructor = function(name) { this.name = name; this.mymethod = function() { alert("my name is : " + this.name); }; }; var SecondConstructor = function(name) { var constructor = new Constructor(name + "bar"); _.bindAll(constructor); _.extend(this, { "mymethod": constructor.mymethod }); }; var obj = new SecondConstructor("foo"); obj.mymethod();

Aquí, SecondConstructor crea una instancia de Constructor para sí mismo en lugar de heredar de él. Luego vincula la referencia de this en todos los métodos de ese objeto constructor para que podamos delegar la llamada a mymethod a nuestro propio objeto constructor. Esto solo funciona para los métodos, pero eso no debería ser un problema porque realmente no debería tener campos públicos.

OOP no es lo mismo en todos los lenguajes de programación. Los objetos en C++ son instancias de clases, y las clases son una construcción completamente en tiempo de compilación. Javascript no tiene clases, todo lo que tiene son objetos.

Es posible usar Javascript de manera que actúe de manera similar a las clases, usando reglas de alcance, cadenas de prototipos y la referencia especial "esto", pero estos son modismos que se imponen en el lenguaje, no forman parte del lenguaje. Y hay bastantes modismos de estilo de clase diferentes de uso común, y un número incalculable de modismos inventados por nosotros mismos.

En mi opinión, las diferencias críticas entre javascript y C++/C#/Java/etc. se entienden mejor explorando las reglas de alcance. Qué variables están en el alcance en cualquier punto del código, y a qué objeto apunta la referencia especial "este", cuándo, es lo que es fundamental comprender, cuando se intenta trabajar con javascript.

Como nota, recientemente comencé a usar Processing.js que permite la declaración de clases C++, simplemente usando 'class' .

Edición posterior (junio de 2014):

Processing.js fue bueno para poner en marcha proyectos sin tener que luchar con JavaScript OOP. Pero cuando comencé a desarrollar proyectos más grandes, noté que Processing.js tiene un nivel de abstracción demasiado alto y que en realidad vale la pena escribir los bits de programación orientada a objetos y la estructura del código completo por sí mismo.

Ahora estoy usando PIXI.js como mi renderizador de lienzo/biblioteca de interacción y estructuro mi código de una manera mucho más limpia usando algunos de los trucos de programación orientada a objetos mencionados anteriormente.