La primer duda es sobre el principio Open/Close. Me encuentro en
el diseño con situaciones en donde implementaria algo de
una forma simple que resuleve el problema actual pero
por querer hacer a la solucion cerrada a
modificaciones posteriores complejizo la solucion aun
excediendo los requerimientos.
Por ejemplo supongamos una
clase Souvenir que se agrege a los vajes y que
la logica sea por cada pais recorrido se cobra el
precio base del sovenir. La solucion seria pasarle
al metodo cobrarSouvenir la cantidad de paises por
lo que paso el viajero, pero por querer aplicar Open/Close y
adelantarme a cambios de requerimiento (por ejemplo que cambie
la logica de cobrado del souvenir) en vez de pasarle la
cantidad de paises directamente le pasaria la
lista de paises, pensando en que el souvenir siempre sabra como
cobrarse si tiene toda la informacion.
La
segunda duda es: se espera que chequee que las fechas de
las estadias/vuelos no se superpongan? Porque si
agrego una estadia que va del 10 de junio al 20 de junio y
despues se agrega un vuelo que se produce el 15 de
junio, semanticamente no tiene sentido (porque una persona
no puede estar en el hotel e irse a la vez) pero las
pruebas pasarian igual de bien (no afectaria a
las duraciones o a los costos).
La tercera duda es
parecida a la segunda y tiene que ver con los paquetes. Uno tiene la
posibilidad de crear paquetes de forma separada a los viajes y
posteriormente agregar un paquete a un viaje. El problema aparece
cuando fechas de cosas del paquete se solapen con cosas del viaje que
no son del paquete. Se espera que se chequee que esto no pase?
Hola Axel,
En cuanto a la primera duda no podés prever absolutamente todos los cambios a futuro que pueda llegar a tener tu aplicación por más que respetes el principio de abierto/cerrado. Puede llegar a darse la situación que requiera una refactorización enorme, por lo que no es recomendable que pienses tan a futuro. La idea de respetar ese principio SOLID para los adicionales sería que todos implementen la misma interfaz o hereden de la misma clase abstracta y entiendan todos el mismo mensaje (que puede ser calcularCosto, modificarPrecio o algo similar), de manera tal que si quisieras agregar un tipo de adicional más a tu modelo solo debas crear la nueva clase e implementar esa interfaz.
En cuanto a las otras dos dudas, se espera que las sepas interpretar a través de las pruebas del enunciado. Todo lo que no esté allí especificado y vos quieras incluir como funcionalidad en tu solución pasa a ser un supuesto y, como tal, debe estar documentado en el informe, justificado y con su conjunto de pruebas unitarias.
En particular yo no veo por qué decís que "semánticamente no tiene sentido" que haya un vuelo en una fecha que se superponga con una estadía. Yo una vez reservé un hotel para un mes y en el medio hice un vuelo a otra ciudad sin cancelar la reserva del hotel. Luego volví a la primera ciudad en tren (que pagué en la boletería) y seguí usando el mismo hotel que había reservado originalmente. Por más que pagué un par de noches que no usé me convenía más eso que cancelar la reserva y hacer una nueva. Hubiera sido algo molesto que el sistema no me permitiera hacer eso.
Saludos,
Tomás
buenisimo, gracias