Patrones de diseño identificados

[MichArceS]

Singleton
Motivación: El repositorio contiene una clase llamada ConexionUtility donde, su principal funcionalidad, es realizar una conexión con la base de datos utilizada en el proyecto. En esta clase es importante tener un Singleton ya que puede existir la posibilidad de que se puedan crear diferentes instancias innecesarias de la misma.
Objetivo: Asegurar la existencia de una única instancia de esta clase para que no existan problemas con muchas conexiones a la base de datos.
Consecuencias: Obtendríamos la seguridad de que no se crearan diferentes conexiones a la base de datos, lo cual ahorraría problemas que se pudieran generar con ella.

Decorator
Motivación: En este proyecto se pueden realizar diferentes compras, y cada una de estas compras se materializan en una clase llamada Venta, y esta última tiene sus detalles en una clase llamada DetalleVenta.
Objetivo: Obtener una manera segura de alterar los detalles de una venta sin necesidad de crear nuevas instancias de la clase.
Consecuencias: Se podrá cambiar los detalles de una venta de forma segura y sin tener que instanciar más clases.

Observer
Motivación: Existen clases que necesitan ser notificadas cuando se realiza cierta acción. En el proyecto está realizada esta tarea con otros medios, pero la utilización del patrón Observer haría el trabajo más sencillo de realizar y de entender.
Objetivo: Poder realizar notificaciones a diferentes controladores para que realicen acciones especificas cuando su estado era actualizado mediante los observadores.
**_Consecuencias:

_** Podremos reducir el acoplamiento que existía anteriormente. También podremos tener notificaciones y actualizaciones más precisas y, en el caso de necesitar más observadores, podremos agregarlos sin tener que alterar los sujetos.