Haciendo un rápido balance de mi primer año en el Máster en Ingeniería Web en la Uniovi, puedo decir que he aprendido mucho, y cuando digo mucho creo que es poco. El enfoque duro de ingeniería de software, el nivel de exigencia y la calidad de los profesores encaja excelente con quienes tomamos a la informática como algo que es mucho más que el trabajo o una diversión, como algo que nos motiva día a día. En este post, que he decidido dividir en tres partes dada su extensión, voy a hablar sobre los patrones de diseño que más me han gustado durante los primeros cursos del Máster. El primer patrón del cual voy a hablar, y sobre el cual trata este post es el patrón Command ( del GOF).
El Patrón Command
Este patrón de diseño es mi favorito, a grandes rasgos permite encapsular cada operación de negocios en lo que se define un “comando” ejecutado por un “ejecutor” que supervisará la correcta ejecución del comando. Gracias a este patrón, es posible en muchos casos que las aplicaciones puedan implementar la característica “deshacer”, ya explicaré el por qué. Revisando en profundidad los componentes del patrón se deben definir los siguientes:
- Comando(Command): Un comando o Command, es una clase que realiza una operación de negocio específica, por ejemplo en un sistema de gestión de ventas, un comando podría ser RealizarVentaCommand, el cual ejecutaría solo una operación de negocio de la aplicación. Esta clase RealizarVentaCommand recibiría como parámetros de la clase todos los atributos necesarios para llevar a cabo la tarea. Ahora, para decir que una clase es un comando, debe cumplir una Interface que nosotros mismos definiremos. Por convención propia la llamaremos ICommand, su particularidad es que posee un método llamado execute sin parámetros y retorna Object. Ahora, si queremos nutrir al comando de alguna lógica extra usando por ejemplo un template method, podemos usar una clase abstracta AbstractCommand con algunas implementaciones ya escritas (por ejemplo algún tipo de Log que también podría ser inyectado). Por último, si queremos que nuestro comando se pueda deshacer, nuestra interface o clase abstracta debería definir el método undo además del execute, el cual en su implementación defina los pasos necesarios para dejar el comando sin efecto.
- Ejecutor de comandos (CommandExecutor): Esta clase será la encargada de ejecutar los comandos, en el fondo lo que hará será que, dado un objeto que cumpla la interfaz ICommand recibido como parámetro, procederá a ejecutar el método execute definido en el comando (por polimorfismo). De esta forma el proceso de ejecución de los comandos estará supervisado por el ejecutor, permitiéndole gestionar errores, realizar rollback de ser necesario o ejecutar operaciones de auditoría u otras llamadas que sean pertinentes. El ejecutor de comandos entonces debería ser una única instancia siempre presente en el sistema (osea un síngleton) y siempre ejecutar comandos pasados como parámetro. Si se requiere implementar la característica “deshacer” se debería generar un mecanismo de acumulación de comandos ejecutados, esto es, por ejemplo dos pilas, una de comandos ejecutados y otra de comandos deshechos, o una lista que se pueda recorrer, en fin, para esto hay varias posibilidades dependiendo del programador. Para que el deshacer funcione correcto cada comando debería implementar la lógica necesaria para deshacer la acción en el método undo definido por la interfaz ICommand.
A nivel general, el diagrama explicativo del patrón es el siguiente:
Voy a dejar un ejemplo de implementación del patrón Command, el código lo implementé como parte de un ejercicio para la asignatura de Arquitectura del máster; a nivel básico este programa es una calculadora que permite sumar, restar, multiplicar y dividir enteros y reales. Para su implementación además del patrón Command, usé el patrón Template Method, Factory Method y el ya tan conocido Singleton. El código está escrito en Java, no está muy comentado, pero está de muy fácil lectura. Si tienen dudas sobre la implementación no duden en comentar.
Aclaro, me di recién cuenta, una vez ya publicada la entrada que el nombre está mal, debería ser:
Mis patrones de diseño favoritos, para evitar malas interpretaciones. =)
