Patrones de comportamientos

[kevin523523]

Iterator

Problema: SalesModel representa el modelo de ventas de la aplicación. Cuando existe un gran número de ventas donde se requiera manipular los objetos de uno a uno, actualmente solo se puede lograr esto a través de un ciclo for utilizando índices.

Solución e implicaciones: Para permitir la iteración a los objetos que representan las ventas, se hizo uso del patrón de comportamiento Iterator. De esta manera, se puede iterar cada uno de los objetos o obtener al siguiente cuando se llame al método iterator().

Observer

Problema: Cuando se realiza una venta existen tareas que se deben ejecutar después de ese evento, por ejemplo el cobro. La implementación que tiene el proyecto ahora mismo para realizar esta función es la estructuración de código para que sea secuencial, lo que genera limitaciones.

Solución e implicaciones: Haciendo uso del patrón de comportamiento Observer, se crea una interface SaleObserver que será implementada en SaleLogger. El logger tendrá funcionalidad que será ejecutada cuando se realice una venta. En SalesModel se guarda ahora una lista de observadores para poder tener acceso a ellos cuando disparen una actualización y poder removerlos con más facilidad.

Strategy

Problema: El código en SupplierModel tiene acoplada la lógica para obtener los proveedores desde la base de datos. Esto lo hace menos flexible y reusable.

Solución e implicaciones:Aplicar el patrón Strategy para desacoplar la lógica de obtención de datos:
Crear interfaz SupplierStrategy con el método getSuppliers()
Implementar estrategias concretas para distintas fuentes (DB, API, etc)
SupplierModel tendrá una referencia a Strategy y delegará la obtención de datos a eso.