Java - Un antipattern de los gordos?

Llevo dos semanas buscando una solución a un problema, al final la he encontrado, pero creo que es un antipatrón de esos que cuando los ves dices: pues se ha quedado a gusto el que ha escrito este codigo ehhh...

Lo que quiero hacer es ir cargando objetos en memoria usando los datos que tengo en un archivo (entidades de un mapa de un juego).
Tras pensar mucho, he tomado la siguiente estructura:

Una clase raiz BasicEntity

AxisEntity extiende BasicEntity y permite tener X e Y junto a algunas funcionalidades para el plano.

VisualizableEntity extiende BasicEntity e implementa la interfaz Visualizable, que tiene los métodos para obtener el frame a renderizar.
VisualizableEntity va a ir siendo extendida, para hacer una clase NPC por ejemplo, una clase Enemigo, jugador, pared, plataforma, etc...

Problema?¿

Pues que al cargar el mapa, usaré reflection para instanciar los objetos según la clase a la que pertenezcan.

Por ejemplo, si el mapa tiene 4 muros de la clase Muro, y 1 personaje de la clase Personaje, crearé las instancias de Muro y de Personaje usando reflection y las voy a guardar en una List<VisualizableEntity>.

Con esto, obligo a tener ciertos constructores en las subclases para que el objeto pueda crearse sin problemas, y esto huele bastante mal.

Escribiendo el post, he tratado de poner alguna de las alternativas que se me ocurrian, pero incluso las alternativas llevan al mismo problema:
que reflection + constructores no se llevan demasiado bien con la herencia (o almenos eso creo por lo que estoy viendo)

Esta descripción se parece a lo que el factory design pattern quiere resolver
(https://www.tutorialspoint.com/design_pattern/factory_pattern.htm).

Esta estructura de clases esta estructura me parece un poco inviable, ya que para cada nueva extensión de la clase raíz hay que actualizar el creador de objetos... Pero con anotaciones, y usando la Class.getClassName() como identificador de que quiere crearse podría llegarse a algo...
Pero como digo en el post, acabamos llegando al mismo punto: las clases que extiendan la raíz se verán obligadas a tener un constructor específico para que el sistema funcione bien. Esto será confuso para los diseñadores de juegos que usen el motor, por no decir a ver como se documenta esto de forma coherente con diagramas UML haha...
Creo que voy a buscar algun motor de juegos Open Source en Java para ver como solventan este problema, si es que lo hacen, porque no sería la primera vez que me encuentro con cosas que no tienen forma de hacerse correctamente por limitaciones del lenguaje

Parece que tienes ganas de buscar tres pies al gato usando reflection pero allá tú.
No defines muy claro lo que pretendes hacer, pero tampoco hay tanto problema:

El mapa se cargará usando una clase que irá creando objetos de los distintos tipos que vaya encontrando en el archivo. Todos los tipos tendrán la misma clase base, pero pueden no implementar el mismo constructor, lo que es un problema.
Creo que habrá que hacer clases compuestas y muy ricas, en las que en lugar de extender, se introducen distintos componentes.

¿ Qué constructores son esos ?
¿ Por qué usas reflection si ya has diseñado las clases que vas a usar ?

VisualizableEntity tiene un constructor que recibe un objeto Visualizable y un objeto EntityBounds.
Reflection se usa para cargar en memoria los mapas del juego.
En los archivos que guardan el mapa, tengo la clase que hay que usar para cada entidad de este.
Por ejemplo: Muro, 100w, 100h, 50x, 50y. Jugador, 100w, 100h, 100x, 100y.
La primera línea carga un objeto Muro con los datos que le específico.
La segunda lo misno con un objeto Jugador.

Estas tomando datos de una fuente de texto y pasandolos a objetos en memoria. Esto se conoce como deserialización.

Dicho esto, si estuvieras usando un lenguaje moderno, el modelo que planteás se podría realizar con un Discriminated Union. En lugar de una jerarquía de clases interminable y tediosa para construir y mantener.

Además de esto, no me parece un buen diseño atar los objetos de tu modelo a la capa de presentación, con esta idea de que cada tipo de entidad "renderice" su propia GUI. Creo que la renderización del frontend NO es una responsabilidad del model.

Lamentablemente ninguno de los frameworks de java soporta una adecuada separación entre las vistas y la lógica de presentación, como la que se logra con paradigmas reactivos o MVVM y DataBinding en frameworks modernos.

Conclusión: yo te diría que te olvides de java y empieces a utlizar tecnología moderna y decente, con lo cual vas a poder realizar tu idea con mucho menos esfuerzo, mucho menos código, y de una forma mucho más mantenible y extensible en general.

Otra cosa: los "patrones de diseño" (de los cuales los programadores java son fanaticos) son simples parches para compensar la deficiencia del lenguaje. En la medida que empieces a utilizar cualquier lenguaje estático moderno (C#, F#, TypeScript, Swift, Kotlin, etc), te vas a dar cuenta que el 80% de los "patrones de diseño" que se usan en java son irrelevantes y obsoletos, al igual que el lenguaje java.

Buenas tardes y muchas gracias por una respuesta tan completa!

Sobre lo que comentas de mi estructura de clases, tú qué harías en mi lugar?
La cosa es que el motor tiene un reloj que en cada tick realiza una serie de operaciones. Cuando quiere añadirse algo a ejecutar por el juego, como una animación, físicas o detectar eventos del teclado, se registra la clase que lo ejecuta en el reloj para que corra cada x ticks.

Sobre las animaciones, texturas y acciones que una entidad puede realizar, se te ocurre alguna forma de programarlo sin tenerlo todo en una clase?
La verdad es que tienes mucha razón sobre que tenerlo centralizado no es buena idea, pues algunas entidades como la cámara, no van a tener textura, o van a ser especiales. Esto sí el programa es simple no se notará, pero a la hora de expandir será un dolor de cabeza!
Algo que se me ocurre (y ahora que pienso en ello, recuerdo que lo hice para la librería de detección de eventos del teclado), es en vez de poner directamente la textura a la entidad, hacer que la entidad tenga un administrador de texturas.

> tú qué harías en mi lugar?

Yo empezaría por no usar java nunca más en la vida, para nada.

¿Por qué? pues porque java es el Reino de los Sustantivos y su increíblemente limitado umbral de abstracción te limita a pensar en los términos en los que se puede pensar en java, y por lo tanto terminás pensando en sustantivos que muchas veces deberían ser verbos.

Dicho esto, parece que estás tratando de reinventar Unity2D. Si la intención es esa, adelante. Pero si tu intención es simplemente crear un juego te diría que hagas uso de alguno de los múltiples game engines que ya existen.

respecto de las distintas capas, se me ocurre rapidamente un mecanismo de messaging para que cada entidad de señales de sus ciclos de vida y las distintas capas los manejan, independientemente del resto de las capas. Despues si puedo te armo un ejemplo, por supuesto no en java.

Pues la verdad es que un pequeño ejemplo me vendría genial, sobretodo ahora que estoy a punto de empezar con partes del motorcito que dependen en gran medida de la estructura que sigan las entidades.

Y sobre lo de dejar de lado Java, estoy en proceso de hacer cambio en mi tiempo de estudio hacia C++.
Este motor es un proyecto de grupo donde, yo que soy el que más se apaña con el tema de estructurar los programas (y aún así mira la de marrones en los que me he metido con la estructura), voy a hacer lo principal, otro seguirá mi trabajo, terminando de pulir cosas y expandir el motor para que lo puedan usar los dos que se encargarán de hacer un juego simple con este.
Hemos sido ambiciosos para el trabajo, y sabemos que el juego irá lento por el tema de que como comentas, Java no es el lenguaje indicado, pero por otro lado, haciendo esto, vamos a toparnos de frente con las limitaciones del lenguaje, y tendremos que trabajar alrededor de estas, entendiendo así de primera mano lo que tiene de bueno y malo, sin basarnos exclusivamente de opiniones leídas en foros y artículos.

>se me ocurre rapidamente un mecanismo de messaging para que cada entidad de señales de sus ciclos de vida
Tiene buena pinta, estaré atento al hilo.

Bueno, acá esta: https://github.com/agleiva/Ejemplos/tree/master/EjemploGame2D

Mejor que cualquier cosa que puedas siquiera soñar con hacer en java, en tan pocas lineas de código.

Te lo explico brevemente:

la MainWindow define un ListBox, cuyo panel es un Canvas, el canvas permite definir las propiedades X (Canvas.Left) e Y (Canvas.Top) de los elementos.

Cada Entidad tiene 4 propiedades basicas: X, Y, Width, Heigth. Estas estan bindeadas a las propiedades visuales. Fijate que no hay codigo en ningun lugar que manipule ningun elemento visual. Esto es la separacion de la que te hablaba antes. La capa de presentacion cumple su funcion de actualizarse a si misma de manera reactiva cuando una propiedad del modelo cambia.

El CsvEntityLoader carga las entidades definidas en el archivo Entities.csv, y setea las 4 propiedades basicas. Para eso usa reflection, solo la primera vez, para crear un diccionario con los tipos de entidad, mapeados segun su respectivo nombre. Despues en todos los casos utiliza este mismo diccionario.

El GameBoard simplemente actua como un contenedor para la lista de entidades. Eventualmente esta clase tendra mas funcionalidad.

Decime si te sirve y lo seguimos elaborando.

Augstin siempre estas en el foro de Java maldiciéndolo... como si tuvieras algún resquemor con Java... estas seguro que no te gusta Java??? o simplemente entras en los foros de Java para hacer de troll??

Yo no "maldije" nada maestro. Si te fijas, cada uno de mis posts aportan información técnica valiosa. Cosa que tu post claramente no hace.

Y si fuera un "troll", debería ser fácil rebatir algo de lo que digo, no? En lugar de llamarme troll, te pido que demuestres qué parte de lo que dije es falaz o incorrecta, con argumentos técnicos y ejemplos de código.

Hola.

El que si parece troll, es Joel. Seguimos esperando el "ejemplo" para usar C# sin .Net

Cesar. aquí tienes MonoDevelop, para programar en C# sobre cualquier plataforma sin utilizar .NET
https://www.monodevelop.com

Error. Como todo programador java, te quedaste en el siglo pasado.

Hoy en día, el término .NET engloba las plataformas .NET Framework, Xamarin (Mono), Unity, .NET Core y UWP. Con lo cuál, usando cualquiera de estas tecnologías en realidad estas usando .NET.

Esto sí es información técnica:
Agustin técnicamente hablando, eres imbécil (y el trol oficial del foro, si eso alimenta tu ego).
Te enlazo una definicón bastante técnica, por si acaso:
https://www.cun.es/diccionario-medico/terminos/imbecilidad

Y, como dicen que está en desuso (en medicina) pongo una más actualizada, la de cretino, para que te revises los síntomas, a ver si coinciden:
https://es.wikipedia.org/wiki/Cretinismo

Precisamente la característica de los trols de la web ("oficio" tan viejo como los mismos foros públicos) es que os importan un pito las razones técnicas y que os "rebatan" o no (Esto es muy informativo, los más jóvenes pueden no estar aún familiarizados con el término) , cualquier cosa vale con el fin de crear cadenas de respuestas interminables y reflotarlas constantemente.

Hay trols mejores que tú. No hay que tener muchos conocimientos, solo un poco de experiencia, para darse cuenta de que en general solamente sueltas latinajos vacíos de significado real.

Es probable que alguien, razonablemente, borre este post, así que me permitiré el efímero capricho de enlazar otra definición de tu actitud trolesca:

https://forum.wordreference.com/threads/mosca-cojonera.1973637/

Con lo de separar vista, también te refieres a que el objeto Animation (que maneja los frames de una animación) esté fuera de Entity?
Lo que tengo ahora mismo en cuanto a gráficos, es una interfaz Visualizable con el método getSprite (un Sprite es un fotograma de animación).
VisualizableEntity extiende XYEntity y contiene un objeto de tipo Visualizable, y a la vez, esta clase implementa Visualizable, con lo que delega el trabajo de calcular que Sprite toca mostrar a el objeto Visualizable que he nombrado antes que tiene, mediante getSprite.
Me suena haber leído esta estructura en algún libro de programación.

Cómo lo ves?

Ahora releyendo lo que he dicho, me doy cuenta que se me olvidó comentar que gracias a esto, a FrameMaker.makeFrame(Visualizable) puedo pasarle directamente las entidades a renderizar para hacer un fotograma.

> Con lo de separar vista, también te refieres a que el objeto Animation (que maneja los frames de una animación) esté fuera de Entity?

Si.

> VisualizableEntity extiende XYEntity y contiene un objeto de tipo Visualizable, y a la vez, esta clase implementa Visualizable, con lo que delega el trabajo de calcular que Sprite toca mostrar a el objeto Visualizable que he nombrado antes que tiene, mediante getSprite.

No está mal, dadas las limitaciones de java.

Comentame si viste mi ejemplo, y que te parece.

He visto tu ejemplo y creo que mas o menos entiendo por donde quieres ir con ello.
Las entidades hacen exclusivamente su trabajo de ir cambiando de estado según los eventos que sucedan en el mapa, e independientemente de esto, se va renderizando el estado de todo.
Duda que tengo:
Supongamos que quiero añadir luciernagas a mi juego. Estas luciernagas, de noche, tienen que hacer un pequeño efecto de luz a su alrededor.
Pues nada, extiendo de la clase Entity y me las ingenio para que estas se vayan moviendo en circulo en bucle.
Ahora como le hago saber al encargado de renderizar el frame que alrededor de esa luciernaga hay que hacer un difuminado de color amarillo, esto sin estar haciendo trabajo que tiene que ver con graficos?

Escribiendo esta pregunta, me doy cuenta que Visualizable no debería ofrecer acceso a una textura, sinó que debería ofrecer cierto "apoyo" para dibujar en el frame, para casos en los que una entidad que quiera hacer un efecto visual que no sea una textura.