Refactoring with Design Patterns

[lizVergara]

Composite.
Objetivo.
Construir menú de opciones complejos mediante la composición recursiva de menús similares, simples o compuestos.

Motivación.
La clase OptionMenu cuenta con todas las posibles opciones que hasta el momento oferta el sistema emulador de un Cajero automático, pero para un futuro que se deseen agregar funcionalidades va a ser obligatorio modificar el código fuente de OptionMenu, lo correcto sería solo añadir a la estructura del sistema la nueva funcionalidad como un módulo independiente.

Consecuencias del rediseño.
Por medio de la estructura basada en el patrón de diseño composite se hizo posible la añadidura de nuevas funcionalidades a un menú ya existente de manera dinámica y sencilla, como suma de un nuevo módulo sin modificar código en otras clases, lo que fortalece la escalabilidad de código e incentiva Open-Clouse Principle.

Decorator.
Objetivo.
Añadir dinámicamente características y funcionalidades para crear diferentes tipos de cuentas.

Motivación.
En la clase original nombrada como Account existían variables y métodos individuales para cuentas de tipo de ahorro y corriente, el problema surge que una cuenta de tipo corriente no usa todos sus métodos y variables de instancia, solo las que significan su tipo y viceversa. Esto es un problema para el uso de memoria, la sencillez de código y la escalabilidad del sistema.

Consecuencias del rediseño.
Mediante la implementación de la estructura del patrón de diseño Decorator se pueden crear futuros tipos de cuentas básicas mediante la extensión de la nueva clase abstracta Account y añadir más decoradores a esos tipos de cuentas para asignar funcionalidades y características adicionales dinámicamente extendiendo de la clase abstracta AccountDecorator, como CollectiveAccount. Con esta refactorización de código en la clase OptionoMenu se trata indistintamente a todas las cuentas.

Diagrama UML de clases.