Feedback Checkpoint 05 Nov

[asanzo]

¡Buenas!

Les dejo esto acá para cuando hagan la corrección presencial con Tom. Como siempre Tom va a agregar/modificar a esto que dejé por acá, charlen con él por cualquier cosa.

Correcciones generales

• Bien por evitar la repetición de lógica entre los objetos aleatorios, impecable laburo, gran uso del template method :+1:
• La repetición de lógica de las configuraciones de las teclas está mejor :+1: pero sigue repitiendo bastante lógica entre los dos métodos keyconfig.jugador1 y jugador2 :-1: . Lo único que cambia son las 4 teclas, que son objetos. Podrían ir por parámetro.
• Muy buenos los agregados: el hielo, los arbustos, los sonidos, el selector de arbustos. ¡Bravo! :clap: :clap: :clap:
• Para pensar durante la corrección presencial: Ok, no usaron colecciones. ¿Por qué no las necesitaron? ¿Cuándo sí hubieran sido necesarias?
• Guarda que en el diagrama estático las clases no van punteadas. Lo que van punteadas son las interfaces, porque son una "idea". Para hablar durante la corrección presencial: ¿Para qué se diagraman las interfaces? ¿Qué muestran? ¿Habría alguna en algún diagrama de su solución?
• El resto de las respuestas teóricas muy bien :+1:
• Los nombres de los describe no se corresponden con lo que se testea. ¿Cuándo están cambiando los modos? El primer y el tercer test prueban lo mismo.
• Los tests son bastante pobres. Podrían haber testeado que cuando le dicen "movete" y hay algo, no se mueve. Pero lo más interesante de testear, lo más rico en lógica, es el método que da un paso persiguiendo o escapándose. Ese sí tiene todo el jugo.

Correcciones obligatorias para aprobación

El TP cumple con lo esperado, y tiene corazón y cabeza, ¡Felicitaciones!

Les dejamos las siguientes correcciones para aprobarlo, que sospechamos que les pueden ayudar bastante para el parcial:

• [x] ¡Bien por los objetos dirección, y por delegarles cosas como la posición¡ :+1: . Pero justo ahí en keyConfig estaría bueno que el personaje en lugar de recibir el mensaje "moverseA", en realidad el mensaje sea "moverseHacia". Con sólo recibir la dirección ya puede moverse, y de paso se la guarda. No hace falta hacer los up(), down(), etc., ya que la dirección ya lo sabe hacer, ya entiende un mensaje que lo hace. Aprovechen el polimorfismo de las direcciones.
• [x] ¡El carpincho y el yaguareté tienen bocha de código copypasteado! A ver si logran reducir al mínimo esa repetición.
• [x] El carpincho y el yaguareté no necesitan guardarse la imagen en un atributo, y no es necesario el método actualizarImagen. ¿Se imaginan cómo hacerlo? Cuando un valor es dependiente de otro, no hay que guardarlo, hay que calcularlo. Esto se toma en el parcial. En este caso, la imagen depende de la orientación.

De más está decir que cualquier cosa que quieran agregarle para el día de la presentación es bienvenida. Es su juego :)

¡Bien! ¡Faltan dos cositas y se aprueba! Les recomendamos que aprovechen las correcciones para estudiar para el parcial, y en cuanto las tengan nos avisan.

[asanzo]

Excelente las correcciones gente. ALTO polimorfismo clavaron para resolver las imágenes de los personajes.

¡El TP está aprobado!