Consideraciones

• La clase Usuario ahora tiene una lista de guardarropas.
• Para las propuestas uso el patrón Command. Esto porque vamos a tener operaciones asíncronas. Las propuestas se van a crear por un usuario en un momento, pero se tienen que efectivizar en el futuro cuando el otro usuario decida si acepta o rechaza:
  • En este caso la interfaz Propuesta hace de Command, dónde se especifican las operaciones que se pueden hacer (Aceptar, Rechazar y Deshacer una propuesta).
  • Las clases PropuestaAgregar y PropuestaQuitar serían los ConcreteCommand que saben como hacer esas operaciones en cada caso. Estas conocen al Guardarropas puesto que es sobre el que se aplica la operacion, y además a la Prenda, porque es la que vamos a agregar/quitar y ademas nos viene bien a la hora de deshacer el cambio.
  • El Receiver sería el Guardarropas donde se va a agregar o quitar la prenda.
  • Estaría faltando un Client y un Invoker. En principio pienso que pueden ser elementos que todavía no modelamos, como la interfaz gráfica. Pensé en hacer que el Usuario haga de Client puesto que es el que propone. Pero para esto el Usuario debería conocer el guardarropas sobre el que se hace la propuesta (o al menos eso sugiere el diagrama del patrón en el paper), y ese no es uno suyo. No me pareció del todo acertado poner un atributo para conocer los guardarropas de los demás usuarios si eso no va a tener mucha utilidad tampoco.
  • También puede que este faltando un lugar donde tener a las propuestas pendientes o aceptadas. En principio pensé que este sería el Guardarropas, pero entonces tendría una doble relación entre Guardarropas y cada Propuesta, que no tiene buena pinta. (O sea, siguiendo el ejemplo del Banco, en este caso Guardarropas cumpliría funciones de Receiver y de Client, lo cual no tiene mucho sentido).