Eventos que se repiten

[JuanManuelRama]

Buenas, estoy con la resolución del TPI3, y estancado hace bastante tiempo en como plantear los eventos que se repiten. Primero pensé en hacerlos polimórficos con los normales, pero esto no haría posible aparezcan varias veces en el calendarío, sino que simplemente aparecerían en distintos lugares del mismo según como se le pregunte. Con esta resolución, además, se complica el comparar si están superpuestos, ya que esta operación en verdad no es polimórifca, y requiere chequear de una forma distinta según si se trata de reptitivo vs repetitvo, único vs único o único vs repetitivo.
Entonces, mi solución alternativa es que el calendario no alamcene eventos, sino generadores de eventos, interfaces que entienden getEventos, retornando una lista de los mismos. El generador simple retornaría uno solo, y el compuesto n. Esto elmina el polimorfismo entre hechos, pero genera otro problema. sobre la repetición infinita de los mimsos. Un parche a esto sería forzar que cada consulta sobre los eventos de un calendario esté acotada por fecha, y donde no tiene sentido (próximo evento o está agendado) forzar un límite arbitrario de tiempo
Ninguna de las soluciones me parece suficientemente buena, aunque la segunda al menos tengo soluciones. Querría saber si estoy por buen camino y debería seguir, o si es algo completamente distinto

[JuanManuelRama]

En el contexto de mi solución, el test unEventoRecurrenteSabeCuantoFaltaParaSuProximaRepeticion no tendría sentido, ya que no hay evento recurrente, solo muchos eventitios. Esto es una señal de que voy mal, o puedo borrarlo sin mayor consecuencia?
También entiendo que, nuestro sistema estar pensado para admitir eventos con recurrencia infinita, pero no debemos imlementarla directamente

[flbulgarelli]

En el contexto de mi solución, el test unEventoRecurrenteSabeCuantoFaltaParaSuProximaRepeticion no tendría sentido, ya que no hay evento recurrente, solo muchos eventitios.

No me queda claro a que te referís con los "eventitos", pero sí, este test sí tiene sentido. Si yo cargo un evento que se repite todos los lunes a las 12hs y hoy es domingo a las 13hs, quiero poder saber que faltan 23 horas.

También entiendo que, nuestro sistema estar pensado para admitir eventos con recurrencia infinita, pero no debemos imlementarla directamente

No nos interesan tanto los eventos que se repiten al infinito (por las consideraciones de alcance que me mencioné en mis comentarios), pero sí nos interesa que puedas modelar eventos con repeticiones arbitrarias. En otras palabras, es importante que puedas crear eventos en cuya definición no haya un límite de repeticiones preestablecido (por ejemplo, deberías poder instanciar un evento que se repite todos los lunes a las 19hs, sin tener que indicar que termina luego de X repeticiones).

[flbulgarelli]

¡Buenas, @JuanManuelRama!

Primero pensé en hacerlos polimórficos con los normales,

Esto tiene sentido. En algún punto te va a convenir que los distintos tipos de eventos tengan comportamiento polimórfico.

pero esto no haría posible aparezcan varias veces en el calendarío, sino que simplemente aparecerían en distintos lugares del mismo según como se le pregunte. Con esta resolución, además, se complica el comparar si están superpuestos, ya que esta operación en verdad no es polimórifca, y requiere chequear de una forma distinta según si se trata de reptitivo vs repetitvo, único vs único o único vs repetitivo.

¿Pero esto evitaría que el comportamiento sea polimorfico? Tené en cuenta que un evento sólo tiene sentido dentro de un calendario, por lo que para encontrar una representación polimórfica vas a tener que pensar en cómo interactúa con éste. Por ejemplo, si tu calendario es tan sólo una lista (finita) de eventos y todo se reduce a filtrar esos eventos en cierto rango de fechas, estoy de acuerdo en que pensarlo polimórficamente será difícil. Pero quizás puedas delegar en los eventos que lo componen el obtener sus propias ocurrencias (que en general, serán únicas, pero en en los repetitivos seguirán un cierto patrón de formación) en un cierto rango. O quizás puedas hacer que los mismos sepan decir cual es su próxima "copia", o que de alguna forma la interacción entre calendarios y eventos produzca listas potencialmente infinitas (streams), o quizás simplemente puedas hacer que sean polimórficos para la mayor parte de las interacciones, pero que los repetitivos tengan algún tratamiento especial.

En otras palabras, alternativas hay muchas, pero probablemente impliquen delegar más en los eventos, dejar de pensarlos como elementos individuales que aparecen una cierta cantidad de veces dentro de una lista finita y/o separar el concepto de evento del concepto de ocurrencia.

[flbulgarelli]

Entonces, mi solución alternativa es que el calendario no alamcene eventos, sino generadores de eventos, interfaces que entienden getEventos, retornando una lista de los mismos. El generador simple retornaría uno solo, y el compuesto n. Esto elmina el polimorfismo entre hechos, pero genera otro problema.

Esta idea es interesante, ¿pero por qué eliminaría el polimorfismo entre eventos? Así descripto parece más bien que estás introduciendo un nuevo concepto (el generador de eventos), separado del evento. Probablemente tus generadores de eventos sean polimórficos, mientras que los eventos que produzcan sean siempre del mismo tipo, entonces no tenga sentido hablar de polimorfismo (sólo habría un único tipo de evento, sin distinguir entre repetitivo y único). Esto así planteado parece análogo a lo que te comentaba antes: eventos (únicos o repetitivos) y ocurrencias (la instancia concreta de ese evento en un momento en el tiempo).

[flbulgarelli]

Un parche a esto sería forzar que cada consulta sobre los eventos de un calendario esté acotada por fecha

Esto tiene mucho sentido, porque nunca vas a consultar eventos sin delimitar claramente el rango de fecha que estás estudiando

y donde no tiene sentido (próximo evento o está agendado) forzar un límite arbitrario de tiempo

Sería interesante poder evitar este límite arbitrario, pero en última instancia, no me parece grave: creo que sería una limitación entendible si no calculara eventos que van a repetirse más allá de la vida de un ser humano. En otras palabras, dado que no estamos creando un sistema para simular eventos geológicos o astronómicos, sino para organizar actividades cotidianas, es razonable que no volvamos más complejo el sistema para modelar situaciones que se van de su alcance.

Ninguna de las soluciones me parece suficientemente buena, aunque la segunda al menos tengo soluciones. Querría saber si estoy por buen camino y debería seguir, o si es algo completamente distinto.

Creo que la solución que planteás (si bien tiene aspectos que no termino de entender) está en el rumbo correcto.