derecho. Así es como veo esto. Primero y ante todo, una cita de @keeto:
quedarse con clase
'' La última parte es importante. Si bien las clases son una muy buena forma de implementar código modular, no son la única forma de hacerlo. Encuentro que hoy en día existe una tendencia desagradable para que algunos desarrolladores usen clases para todo. Al igual que el martillo proverbial, las clases se utilizan para cada clave de codificación, lo cual es desafortunado, porque no se supone que todas las clases sean clases.
Las clases son geniales para crear código reutilizable que se puede usar en todos los proyectos, y me apego personalmente a ese criterio. A menos que esté seguro de que algo que estoy creando se usará más de una vez, no lo convertiré en una clase. Y en caso de que no lo haya notado, puede usar MooTools sin tener que definir una sola clase personalizada. Después de todo, solo porque MooTools tenga clases no significa que tendrás que codificar en JavaScript como si fuera Java. * ''
Fuente: http://keetology.com/blog/2010/10/01/modules-and-callbacks-going-hollywood-with-mootools
Esto es muy subjetiva ya que depende en gran medida de la forma de escribir sus clases y Javascript en general.
El uso de una clase NO es sin una penalización y una sobrecarga. Dependiendo del tipo de clase que instancia, esto será diferente. Por ejemplo, si su clase es una simple abstracción de datos que no toca otros objetos o que sale al DOM, es relativamente barato hacer instancias. Los costos estarán alrededor de los objetos de opciones de procesamiento y (a veces) de las propiedades de copia en el constructor de su instancia.
Durante definición de clase en sí, MooTools hace bucle a través de todas las propiedades del objeto constructor y trata de hacer frente a todos los especiales y los mutadores (por ejemplo, initialize, Implements, Extends, binds (de -más), etc). Sin embargo, esto es algo único. Una vez que se ha creado la función constructora, puede usarla rápidamente.
También hará algo más: ajustará todas las propiedades que tengan valores de función para que pueda decorarlas como privadas (a través de .protect() en la API actual) para que cualquier función que ejecute se curried por usted. Además, a menudo tiende a utilizar .bind() como decoradores de métodos, lo que significa 2 envoltorios para el código real que se ejecuta.
Cuanto más complicada es su clase (extendiendo e implementando desde prototipos de diferentes clases), más trabajo puede involucrarse en la creación de instancias de su clase. En realidad, necesita crear un monstruo absoluto para comenzar a notar esto como algo más que la asignación de memoria (retrasos en el inicio o la recolección de basura). Por supuesto, las cosas de cpu-heavy o async/blocking en las funciones de constructor tampoco serán buenas, si lo haces muchas veces ...
Los eventos, los detectores de eventos y demás también pueden acumularse. Las referencias guardadas a los objetos se acumularán con el tiempo.
Entonces, hay clases que se unen a los elementos DOM, añadir eventos, escuchar eventos, exportar sus propios eventos ...
poner todo junto y puede convertirse en algo costoso. Está creando Objetos que heredan (con suerte por referencia a través de la cadena de prototipos) desde muchos lugares. Aun así, la definición de los constructores de su clase es rápida y no será hasta que cree miles de instancias que las cosas comenzarán a ponerse interesantes y pondrá a prueba un navegador moderno.
¿qué gastos generales de DOM? una clase es un objeto y si no crea nada en el DOM, entonces la huella no irá allí. los objetos también se pasan por referencia y la herencia no se copiará de otros objetos (a menos que 'implemente', en cuyo punto copiará las claves de objetos). ¿cuál sería tu caso de uso? cientos o miles de clases parecen un antipatrón. la huella más grande será el tiempo de creación/procesamiento, así como todo el ajuste del método que tiene lugar ... por favor elabore un poco sobre sus necesidades –
Gracias por su comentario. Mi caso de uso que estoy imaginando es mapear un conjunto de datos del servidor en un objeto DTO. Esta lista puede ser de cualquier longitud. Así que estoy pensando que en lugar de tener una matriz de objetos {} -style, para cada uno, haga una instancia de, por ejemplo, un PostCodeDTO y colóquelo en la matriz. Básicamente envolviendo el elemento de devoluciones en un Objeto DTO usando por ejemplo los atributos de Mixin for Class y creando un DTO prober con getters y setters, etc. –
parece que podría adoptar algo como [astillero] (https://github.com/seanmonstar/ Shipyard) o [neuro] (https://github.com/GCheung55/Neuro) o incluso Ember o Backbone - un modelo -> estructura de la colección y simplemente defina sus modelos, luego déjelos manejar en una colección y coseche eventos para cualquier propósito/vista. –