[M0] Clase Evento

[alvarogaro]

Buenas @marcosrmartin, he estado comentando algunas dudas respecto a tu proyecto con el profesor y me ha recomendado abrirte un issue relacionado con #2. He estado leyendo la historia de usuario que es sobre la cual voy a trabajar ya que es la que esta asociada con el M0 y había pensado crear la clase Evento ( Sería la clase principal sobre la que se movería todo el problema) por tanto me gustaría que me enfocaras un poco sobre como tienes pensado que se implemente, es decir, que elementos tienes pensado guardar en el: Ejem: ( Fecha, Nombre, (Fecha Tope Pago ??)...)

Cuando me digas mas o menos lo que tienes pensado me pongo a ello :banjo:

[marcosrmartin]

Pues tenía pensado tener los siguientes datos:

• Nombre.
• Descripción.
• Participantes.
• Histórico (De quien realiza cada pago o lo modifica).
• Lista de pagos.
• Gasto de cada participante.
• Gasto total.
• Divisa

En cuanto a fecha tope pago, no lo pondría ya que no es un atributo que realmente vaya a aportar a la aplicación, con esto me refiero a que no sucederá ninguna funcionalidad en la aplicación al llegar dicha fecha, y nadie ha pagado ese día.

Si ves que se podría modificar o añadir algún atributo coméntamelo. 🥶

[alvarogaro]

Buenas @marcosrmartin, estoy con la estructura de datos del evento y tengo algunas dudas: 1º Respecto a los Pagos veo que en el histórico almacenaríamos el pago que se ha realizado y quien lo ha realizado, por tanto el atributo de Lista de Pagos creo que en un principio no sería necesario ya que se podría obtener directamente del Histórico. 2º Respecto al Histórico, había pensado representarlo como un Map donde asociemos el nombre de un usuario con el pago que realiza. 3º Para el tema de las divisas, tenía pensado crear un enumerado que contenga todas las divisas que existen actualmente de manera que el valor que le damos no se puede salir de estos valores. Espero tu respuesta sobre que te parece esto que te comento y si tienes alguna sugerencia o algo dímelo :sauropod:

[marcosrmartin]

Hola @alvarogaro, vamos con las dudas: 1º Creo que no sería prescindible Lista de Pagos (al menos con esta estructura), ya que esta almacenaría valores aparte de quien paga y el precio, además puede haber varias entradas para el mismo pago con diferentes fechas de modificación. 2º Un map no se podría utilizar, ya que cada usuario puede tener más de un pago, y en los maps las claves no pueden estar repetidas. Imagina el histórico como un log, donde los cambios se van anotando en el momento que ocurren. Por ejemplo, una clave para un map podría ser usuario+fecha (ya que un usuario no puede hacer 2 modificaciones a la vez), o con un multimap, la clave podría ser o el usuario o la fecha (las modificaciones se agruparían o por usuarios o por fechas), estas son dos estructuras de ejemplo, pero no se si existiría otra diferente que encajase mejor. 3º Perfecto.

Creo que primero deberíamos ir mejor con el #11, ya que esta ED depende de las otras dos y así sería más fácil. 🤙