Consulta frecuencia

[Maiarguelles]

https://github.com/Maiarguelles/algo3-tp-2023c1/blob/2a1dbe50bdda12a3a1077b7af22664d12a9f630f/src/main/java/InfiniteRepetition.java#L18 Buenas noches, tenemos una consulta sobre el diseño de la frecuencia. Nosotros lo que hicimos fue crear una clase repeticion, con subclases que sean repeticion infinita, repeticion por ocurrencias, o repeticion hasta una fecha. Por otro lado, en la clase repeticion tenemos un ENUM frequencyType. Lo hicimos de esta forma por que creimos que hacer clase de tipos de frecuencia y tipos de repeticion era demasiado choclo de clases y se complicaba calcular ciertas cosas por los datos a los que accedia una clase y los que no, etc. El problema es que con esta implementacion, al tener que tener en cuenta los distintos escenarios, nos quedan funciones como estas, que son un if else abajo del otro, queriamos saber realmente que tan mal esta, o si vale la pena. La otra que pensabamos era hacer subclases del estilo EventDaily, EventWeekly, etc.. pero tampoco nos solucionaria el hecho de que en repetition, todo se calcula en funcion del tipo de frecuencia y eso nos lleva a mucho codigo repetido. El metodo citado es justo el showEvents que muestra los eventos entre dos fechas, aunque no es necesario entregarlo, este metodo nos hizo replantear si estabamos diseñando bien las cosas y queriamos ver si podias darnos un poco de orientacion con esto.

[Milidoni0cris]

Otra solución que nos facilitaría todo pero dudo que este correcto, es hacer por ejemplo clases que extiendan repetition pero que sean como repetitionInfinityWeekly, repetitionByOcurrencesDaily, etc. Serian 12 clases pero apuntarían a algo tan especifico que creo que facilitaría hacer ciertas cosas. Aunque siento que serian demasiadas clases.

[dessaya]

Tal vez lo que van a ver en la próxima teórica (patrones de diseño) los va a ayudar.

Mientras tanto puedo decir esto: la cadena de ifs se debería poder resolver con polimorfismo. En lugar de:

Cosa x;
if (x == caso1) {
  // hacer algo con algoritmo 1
} else if (x == caso2) {
  // hacer algo con algoritmo 2
}

la idea es aplicar "tell, don't ask":

Cosa x;
x.hacerAlgo();

donde Cosa es una interfaz o clase abstracta y hacerAlgo() es un método polimórfico.

Además, tengan en cuenta que los enum en Java son muy versátiles. Vean el ejemplo de la clase Planet acá: https://docs.oracle.com/javase/tutorial/java/javaOO/enum.html (hoy en clase lo voy a mostrar igual).

[Maiarguelles]

Buenas! Estuvimos charlando el tema de strategy para nuestro tp... pensabamos que el enum frequency podiamos meterle un metodo que reciba una interfaz frequencyStrategy (y que lo implementen los 3 tipos de frecuencia), algo del estilo de: public enum frequency{ DAILY, WEEKLY, etc..

public method calcularEventoEntre2fechas(fecha1,fecha2, frequencyStrategy f){ f.calcularEventosEntre(fecha1,fecha2) } etc. Algo de ese estilo nos parecio que era la solucion a lo que hiciste incapie en la clase de los enum que se comportaban de formas distintas. Nuestro problema es que en particular, no podriamos por ejemplo guardar un WEEKLY en evento, sin guardar la lista de dias de la semana, por que en el enum no podemos guardar los atributos particulares de cada tipo en ningun lado. Seguimos pensando en directamente usar Strategy en Evento como atributo, y volar los enums, pero ahora me quede con la duda de que ganabamos en particular con los enums y si vale la pena buscarle la vuelta.

[dessaya]

Bien pensado lo del strategy!

Y está bien, si el enum les trae más problemas que soluciones no lo usen. Es cierto que cuando las diferentes opciones del enum tienen comportamientos muy diferentes ya no se justifica tanto.