smaraggi
commented
2 years ago Hola, les respondo por partes.
- Tiendas en Piso Superior.
En su planteo ya mencionaron 4 patrones que van a usar para el TP: Abstract Factory/Prototype, State, Flyweight y Command. Una solución más natural al armado de las tiendas podría ser un Factory Method. No obstante, ya están usando bastantes patrones.
Los patrones son diseños robustos y probados, que dan flexibilidad, adaptabilidad y robusteza a un diseño. Sin embargo, para proyectos en general conviene evaluar también el ALCANCE de lo que se va a implementar. ¿Realmente va a usarse una clase que permita definir disintos tipos de tiendas que justifique realizar abstracciones? Probablemente no, porque terminada la materia es dudoso que vayan a extender el juego, y si emprenden esa tarea, tranquilamente pueden reemplazar una implementación pequeña por otra más potente. Lo que quiero decir, es que no planteen un sistema que esté abierto a todo tipo de modificaciones a futuro, que luego no se van a realizar.
Igual, si lo quieren hacer de esa manera, con un factory method por ejemplo, no estaría mal y no sería tan terrible tampoco. Pero dense permiso para implementar algo concreto y específico para el problema que van a resolver. Elegir los patrones a implementar y dónde se va a hacer que un sistema sea flexible y adaptable a diversas condiciones es una elección casi estratégica. Ya con otros 4 patrones en curso, busquen la mejor opción para ustedes. Dicho esto, si lo quieren hacer con el patrón está perfecto. Si quieren hacer una clase que configure el piso y que tenga predefinido el tema de las tiendas, también está perfecto. Piensen en un juego de ajedrez: las piezas se saben de antemano y son siempre las mismas; de igual manera, el juego de ustedes, tiene reglas y son estables; por lo tanto, las tiendas ya saben cuáles van a ser y hasta podrían predefinir que estén siempre en el mismo lugar. Hagan como les convenga con esto.
- Terreno en Suelo.
Entiendo que PisoSuperior es aquel que da al cielo y sería la planta baja de un edificio, en tanto que la 1er fila de terreno de suelo sería el 1er subsuelo. Les convendría una factory que maneje por parámetro el tamaño del terreno y que genere un mapa bloque a bloque con el patrón que van a usar y los agrupe en una matriz. Fíjense si en vez de Abstract Factory prefieren usar Factory Method (es un método, no una familia de fábricas de clases diferentes para cada clase de objeto). Pero esto evalúenlo ustedes comparando los dos patrones. Lo importante es que usen un patrón de creación que resulte apropiado al problema. Por abstract factory tendrían una fábrica para cada tipo de casillero (si entiendo que es lo que quieren hacer), mientras que factory method podría ser un poco más chico en código y sortear el tipo de cada casillero a crear para cada lugar en la matriz.
3.a Interfaz Bloque.
No está mal que haya una interfaz bloque y que los 4 tipos distintos de bloque la implementen. Una buena costumbre es que en vez de "Letra", que es una cosa muy general (parecido a "número"... ¿qué sería número?), usen nombres que refieran a la función de eso, por ejemplo, sería más claro "IDBloqueTerreno". Pueden dejar letra igual ahora. Bloque además podría tener un tiempo de minado y un get de recursos, si el bloque tiene o no algún mineral, no se si iban a implementar eso dentro de bloque.
Por ejemplo, podría ser que bloque tenga: getLetra(); (o getTipoDeBloque se podría llamar, mejor aún), getTiempoDeMinado(); getRecursoLocal(); (si tiene algún diamante, por ejemplo). Si van a hacer que cada bloque tenga puntos de vida deducibles con el minado (jugador mina el 50%, se va y luego vuelve y mina el 50% restante) podrían hacer que bloque tenga además "puntso de vida". Eso a su criterio.
3.b Vista de Tiendas
Si, conviene separar la vista de la tienda. Pueden hacer que la tienda reciba una función como parámetro para llamar cuando tenga que reportar algo a la vista. Acá podría usarse el patrón observer, pero como les dije, ya tienen bastantes patrones en implementación, así que mantengamos el scope del TP dentro de algo manejable. Si implementan que la tienda reciba una función, lo que pueden hacer es que cuando tenga que informar las opciones pase la data a la función. De esta manera pueden implementar temporalmente una función que imprima por pantalla, y más adelante cambiarla por otra que llame a las clases de la GUI correspondientes.
-
Se pueden reducir las clases no aplicando sobre diseños. ¿Por qué "configPiso", configPisoSuperior y configSuelo? Acá me parece que los nombres de las clases no me sugieren la verdadera función. Veo que ConfigSuelo es una interfaz para consultar la data del suelo, ¿pero por qué se llama Config entonces si no hace una configuración? Podrían llamarla "Suelo", se me ocurre, y sería más intuitivo. Cuiden los nombres de las clases, para que sean descriptivos de la función que cumplen en el sistema, y lo mismo los atributos de clase (recuerden lo que les dije de "Letra", vuelquen significado y sentido semántico a los nombres, esto les facilita a ustedes mismos cuando tengan que volver a una parte del programa que hayan hecho hace timepo).
-
Está perfecto que Jugador se reparta en clases más específicas. Es un buen ejemplo de cómo más clases puede no ser malo. Recuerden el principio "Single Responsability Class". Inventario es distinta responsabilidad de jugador, lo mismo que nave, me parece una excelente idea.
6.a
Ahora entiendo lo de flyweight mejor en su propuesta. Podrían tener instancias de bloques diferentes en la matriz del escenario, pero que cada bloque tenga una referencia al flyweight de su componente gráfico. Es decir, me cierra mucho que los bloques tengan su propia instancia en la matriz del escenario, y que cada bloque tenga un flyweight para su elemento gráfico, como explicaron ustedes, genial. Esto les posibilitaría ahorrar memoria guardando una sola vez la imagen, y a la vez que cada bloque tenga sus propiedades en el escenario (como un mineral o recurso especial, vida restante, etc., ... si así lo quisiera, por supuesto). Si flyweight lo aplican a la parte gráfica, pueden no incluirlo en esta entrega completo, sino el esqueleto al que luego le agreguen los componentes gráficos.
6.b
Acá me dicen que usan factory method, que es lo que yo vería más adecuado, pero antes me dijeron que usan abstract factory. Son dos patrones disintos, vean porfa la diferencia para saber cual están usando.
claram97
fe-martinez
En el paquete Terreno, al crear el PisoSuperior, ocurría que había que pasarle ciertas Tiendas al constructor. En ese sentido, recibir una lista de Tiendas parecía más sensato que recibir ciertas Tiendas, ya que eso permitiría más flexibilidad (podría decidir de antemano qué Tiendas van a estar en el PisoSuperior y cambiar de decisión solamente haciendo cambios en la lista que le envío). Sin embargo, había que crear todas las Tiendas en algún lado, y esto se estaba haciendo en el Main, lo cual no quedaba muy prolijo. En ese momento se nos ocurrió que era una buena idea pasar todo eso a una clase que cree las Tiendas y las meta en una lista. Por eso se creó la interfaz ConfigPiso que puede implementar distintas configuraciones, entonces PisoSuperior recibiría una configuración y la configuración se ocuparía de iniciar las tiendas y la lista de Tiendas. Sin embargo, al crear las Tiendas dentro de cada clase de Configuración nos quedaron dependencias implícitas, por lo que nos gustaría recibir sugerencias en cuanto a cómo podríamos modificarlo, quizás la idea no fue la mejor. En principio, recibir las Tiendas por parámetro condicionaba qué Tiendas tenían que estar y qué tiendas no y en qué cantidad, pero quizás esto era más conveniente que como está ahora.
En el paquete Terreno, al crear el Suelo, hicimos lo mismo que con el PisoSuperior. La idea era poder crear Suelos predeterminados, ¿vale la pena o es mejor que simplemente se creen bloques al azar en la clase Suelo y ya?
La interfaz Bloque medio que no tiene mucho sentido por ahora. Lo que no sabemos es si va a ser necesaria eventualmente con la GUI (cambiando la interfaz por completo) o si la vamos a terminar eliminando. Esa interfaz fue de lo primero que hicimos cuando creamos el juego porque teníamos una matriz de Bloques y fue quedando, pero ahora no tiene mucha razón de ser. Seguramente tengamos que mirar mejor el trabajo y hacer cambios, pero cualquier sugerencia al respecto sera bien recibida. -Todas las Tiendas de momento imprimen por consola las opciones correspondientes, pero lo hacen en su propia clase. En el futuro las Tiendas en realidad mostrarán las opciones en una pantallita interactiva, ¿conviene entonces separar la vista de las Tiendas de la propia clase?
Tenemos muchas clases, ¿tendríamos que ver la manera de reducirlas?
La clase Jugador era muy larga, por lo que la dividimos en Jugador, Nave e Inventario. ¿Conviene así o mejor lo volvemos a juntar?
Usamos Factory Method para crear los Minerales, la idea es implementar Flyweight para gestionar las multiples instancias de bloques que tienen imágenes iguales y State para cuando los movimientos de la maquina sean mas evidentes (volar, cavar, andar) al momento de hacer una version mas dinamica con JavaFX. Command tambien esta siendo aplicado en parte en Juego, faltaria una manera de customizar los controles, no?