smaraggi
commented
1 year ago Hola, voy de lo más específico a lo más general.
1) El caso de aplicación es típico de factory method. Les recomiendo leer bien el patrón (lo entendieron bien, digo leerlo nunca está de más y les va a dar más pistoas de cómo seguir). Factory method es uno de los patrones más comunes, algunos siempre se usan más que otros, y este es uno de los más comunes. Comentario al margen, así que está bien su uso en este caso.
2) Respecto de clases anémicas, no está mal tener clases muy chicas, si esto prevé una futura extensión del sistema o alguna flexibilización. A futuro imagínense que dentro de un bloque de tal tipo podría haber X chance de encontrar un diamante. Ese tipo de cosas, extensibilidad flexible, se ve favorecido por diseños bien planteados. Es el objetivo de la materia que hagan buenos diseños, sin por ello caer en hacer algo desproporcionado. Una clase por tipo de mineral podría no ser excesivo, y de hecho resultaría bastante natural al paradigma de objetos.
Recuerden que la POO (prog. orientada a objetos, en inglés OOP) brilla para desarrollar sistemas de tamaño medio a grande, y en este caso este tp sería tamaño de chico a chico mediano, en el peor de los casos.
3) Respecto del mapa o escenario, sería muy lógico una estructura interna de matriz. En general, va a tener que ser una collection de bloques. La forma de matriz resultaría bastante intuitiva, porque podrían usar las coordenadas directamente para acceder a los bloques correspondientes. Esto de acceder por coordenadas directamente sería lo más óptimo desde el punto de vista de los algoritmos. Otra posibilidad serían listas de filas... ¿pero no sería eso una matriz? Claro que si. Otras estructuras no matriciales podrían ser una única lista, en que cada [cantidad_elementos_por_fila] se considere qeu empieza una nueva lista... pero es una forma poco clara desde el código de acceder a una matriz.
Piensen en un simulador de vuelo... los terrenos son matrices gigantes de datos, con datos de altitud (respecto del cero del terreno) y datos de textura (luego se agregan los arbolitos y otras cosas, me refiero solamente al terreno). Para simuladores de vuelo se usan optimizaciones como simplificar los datos demasiado lejanos (manejo de nivel de detalle según la distancia para computar menos datos). El terreno de ustedes, si fuera muy enorme y gigante (mucho más allá de loque van a hacer) y tuvieran que visualizarlo de lejos, podría considerar estas técnicas de submuestreo de datos. Eso no va a ser necesario, por lo que una matriz de bloques resultaría muy natural.
Menciono lo de los niveles de detalle por si se les ocurrió pensar ese tipo de cosas. No sería el caso para este trabajo, por la forma en que está definido, así que una matriz andaría fantástico y sería muy natural. Sería, de hecho, la forma más natural de plantear el código, porque se plantea con la misma forma natural en que definiríamos los datos. Siempre que se pueda es bueno definir los datos tan cercanamente a la realidad como sea posible.
4) En cuanto a las pruebas, pueden ir probando por "capas". Escriban clases de bloque, y pruebas para los bloques (sencillas, nada raro). Escriban la matriz, y hacen pruebas de matriz (sin inmiscuirse en detalles de bloques). Luego pueden hacer pruebas de integración, definen una matriz chica, le cargan algunos bloques, y hacen pruebas de la matriz con los bloques interiores y ven que por ejemplo el tipo de bloque y alguna característica más la pueden levantar bien de la matriz.
Cuando hablo de matriz, me refiero al "escenario". Siempre los nombres hagan que refieran a los elementos del dominio del problema, y no a las estructuras de datos internos. Entoces, en vez de matriz, estamos hablando del "escenario"... yo dije matriz para que me entiendan mejor de a qué me estaba refiriendo.
No hay problema si quieren ir chequeando cómo vienen. Traten de meter buena funcionalidad y preguntan, digo, no pregunten cada if que agregan porque se van a demorar y nos vamos a volver todos locos.
Vienen bien con lo planteado.
fe-martinez
Tenemos una serie de dudas. Por un lado, nuestro juego tiene un nivel único, siempre va a tener la misma profundidad, lo único que cambia es que se generan aleatoriamente los minerales que junta el personaje. A raíz de esto: 1- Estuvimos discutiendo sobre qué estructura de datos era mejor. De momento solo tenemos una matriz pero creemos que quizás haya alguna opción mejor. Pensamos en la matriz porque para este punto del proyecto visualmente el juego se ve como una matriz de char en la consola. 2- Terreno es un conjunto de bloques, donde cada entidad del juego (jugador, bloques de minerales, bloques de tierra, tiendas, aire/espacio vacio) implementa a la interfaz bloque. Las interacciones entre jugador y los varios elementos se hacen chequeando la matriz donde están todos metidos. La pregunta es, seria mejor tener todo junto en una única estructura (creando una clase con muchos componentes y difícil de probar) o tener cada tipo de elemento por separado en una estructura de dichos elementos y chequear las colisiones/interacciones con cada una. Por otro lado, tenemos las siguientes dudas: 3- Tenemos una fábrica de minerales, en este momento está hecho con un enum no más, pero estábamos pensando en que aplicar bien el patrón factory method hace que hagamos una clase para mineral, y lo único en lo que van a variar es en que cada uno tiene un precio diferente, son clases re anémicas también, ¿conviene que las creemos? Porque así hecho con el enum se viola el principio open/closed porque la fabrica está llena de ifs que devuelve un Mineral con un tipo de enum distinto, pero no sabemos si conviene crear clases que varían en poco y nada. 4- Algunas pruebas seguramente van a cambiar en la etapa 3 del TP. ¿Se presentan las pruebas como estan ahora y después se vuelven a presentar las nuevas pruebas? 5- ¿Se puede hacer algún tipo de pre-entrega para ver cómo vamos? De ser posible, ¿bajo qué condiciones sería?