javascript: ¿varias clases "almacenadas" dentro de un objeto?

0

Tengo la sensación de que hay algo terriblemente mal con la forma en que apilé varias clases en el siguiente ejemplo: (p. Ej., Este ejemplo es solo para mostrar el patrón al que me refiero)

const itemClasses = {
    ItemOne: class {
            constructor (somethings) {
                        this.thatThing = somethings;
                    }
            doThing() {
                        /*some code*/
                    }
            },
    ItemTwo: class {
            constructor (somethings) {
                        this.thatThing = somethings;
                    }
            doThing() {
                        /*Do another thing!*/
                    }
            }
}

Hago la pregunta ya que mientras trato de aprender los conceptos básicos solo encuentro ejemplos de clases que se definen globalmente con "clase XX ()"

Me parece genial reunir clases en objetos por dos razones.

  1. Mantiene el espacio de nombres más limpio cuando se utilizan muchas clases más pequeñas.
  2. Puede elegir mediante programación diferentes clases más fácilmente: Como:
    new entity[variable](param)

¿Se necesitan recursos de costo (ram / cpu) para poner clases dentro de "objetos padres" o hay alguna otra razón para no apilar clases como esta?

Si no hay problemas, estaría bien dar un paso más y anidar así:

 const classes = {
    items = {
        /*Classes in here*/
    },
    entities = {
        /*Classes in here*/
    }
}

PD. He recibido el gran consejo de usar [la sintaxis del módulo ES]. Todavía tengo que entender la sintaxis del módulo que ofrece principalmente beneficios de legibilidad o si también hay otras ganancias sustanciales, investigándolo = D Gracias por sus respuestas hasta ahora.

5
  • 2
    Está. Haga que sus clases sean declaraciones de clase normales, y luego puede agregarlas trivialmente si lo desea, pero la sintaxis del módulo ES ya le permite hacer esto de una manera aún mejor que la que está mostrando. Exporte ambas clases desde un archivo, luego impórtelas en lo que sea que las necesite import { Item, Enemy } from "./my-game-classes.js";Y luego, si realmente lo desea, puede declarar const entities = { Item, Enemy };para poder construirlas a ciegas, pero un buen código no debería necesitar eso: debería ser bastante limpio cuando algo es un elemento vs .cuando es un enemigo, con constructores explícitos. 13 de oct a las 15:56
  • Hola, gracias por tu rápida respuesta @ Mike'Pomax'Kamermans! <3 Eres un héroe por prestarme parte de tu tiempo = D Incluso como principiante, entiendo que debería haber una clara diferencia entre me gusta, un objeto y enemigo = D, ejemplo = S En el uso real, estoy mirando diferentes tipos de básicamente la misma cosa. con muy pocas diferencias en algunos métodos de prototipo. (Dibujando cosas sobre lienzo) Eso es además del punto en el que tú = DI tenía la sensación de que me estaba perdiendo algo grande conceptualmente. ¿Podría explicar / vincular por qué las declaraciones de clase normales son mejores / cuál es la diferencia (además de la legibilidad) 13 de oct a las 19:01
  • Entonces, recomendaría encarecidamente dedicar un poco de tiempo a mejorar su publicación para que pueda mostrar un ejemplo bien elaborado y cercano al mundo real que ilustre lo que está haciendo. La gente va a criticar el código que muestra, así que asegúrese de que no estén criticando las partes equivocadas =) 13 oct a las 19:34
  • Sí, debería haber dedicado más tiempo a inventar el ejemplo. O al menos tener más claro lo que buscaba. TBH realmente no tengo un ejemplo del mundo real en el que basar mi pregunta, solo estoy tratando de comprender las diferentes formas de escribir / iniciar objetos y trabajar con prototipos. Leeré el enlace y me aseguraré de hacer una mejor formulación la próxima vez (si me atrevo a intentarlo de nuevo, jeje). ¡Gracias una vez más @ Mike'Pomax'Kamermans por prestarme algo de tiempo! Echaré un vistazo a la sintaxis del módulo ES para entender por qué es mejor. 13 de oct a las 20:01
  • 1
    sugerencia sugerencia sugerencia : el botón de edición está allí, no digas simplemente "Debería haberlo hecho", hazlo y luego actualiza tu publicación . El proceso no se detiene ahora que ha publicado: todavía está en el asiento del conductor y aún debe asegurarse de que su publicación se actualice para reflejar mejor su problema, incluso después del envío inicial. 13 de oct a las 23:11
0

Does it take alot more memory, or is it slower?

No, es un patrón totalmente bueno. Los espacios de nombres ayudan con la organización del código, aunque se sienten un poco anticuados: los módulos ES6 son el camino a seguir.

Are there any other reason not to do this?

El ejemplo que diste

new entity[variable]("xx", "yy")

está roto. Esto solo funciona si todas sus clases tienen la misma firma de constructor, pero en su ejemplo ItemOnetoma un color y un tamaño, mientras que ItemTwotoma un tipo y un valor. Pasar "yy"como valor no funciona ya que ItemOneespera un número como tamaño.

Tal vez sea solo por el ejemplo bosquejado rápidamente, pero tenga esto en cuenta. Por supuesto, todavía hay casos en los que necesita resolver clases por nombre incluso si los tipos de parámetros no coinciden, pero deberá asegurarse de que los argumentos encajen.

3
  • Muchas gracias por tu respuesta @Bergi Sí, parece que mi ejemplo esbozado rápidamente realmente me mordió en mi * ss. ¡Lamento muchísimo haber hecho que el problema sea más difícil de entender! No tengo un proyecto del mundo real en el que basarlo, solo trato de entender las clases, las funciones de constructor, las funciones de fábrica, los prototipos, etc. ¡descubra por qué es la mejor opción para varias clases! ¡Muchísimas gracias por su tiempo! 13 de oct a las 20:08
  • 1
    @HappyImbecile No, no es " la mejor opción para múltiples clases ", es la mejor opción para cualquier cosa que desee poner en un objeto de espacio de nombres
    Bergi
    13 de oct a las 21:16
  • Aaah ok :) gracias de nuevo! 13 oct a las 21:33