Command pattern

Designing and Developing Enterprise Applications

PATTERN COMMAND JOSEPH QUIMÍ GONZÁLEZ

COMMAND PATTERN Patrón de Conducta Propósito: Encapsular una petición como un objeto permitiendo la parametrización de los mismos (inicialización de los parámetros por el constructor), la gestión de colas para peticiones múltiples (estructura de datos de objetos command) y su reordenación. Permiteademás, implementar el hacer y deshacer (Execute/Unexecute) de peticiones. También conocido como: Action, Transaction Motivación: A veces, se necesita poder enviar solicitudes a objetos sin tener idea de la operación solicitada ni del receptor de la solicitud. Por ejemplo en un objeto del tipo botón o menú, estos objetos ejecutan acciones que no son implementadas por ellos. Este patrón presenta, de formasimple, una manera de implementar un sistema basado en acciones que permita su extensibilidad y mantenimiento. Problema: Un procesador de texto como Microsoft Word. Este, como muchos editores de texto, incluyen un grupo de funcionalidades aplicadas mediante botones o elementos del menú se ha copiar, mover, cortar entre otras tareas. Con el objetivo de personalizar la funcionalidad de estoseditores a los diversos gustos de sus usuarios, se implementan varias maneras de realizar las mismas acciones. Por ejemplo, retornando a Microsoft Word, es posible cortar un texto mediante un botón de la barra de herramientas, mediante el menú de edición o utilizando el acceso rápido del teclado (CTRL+C). Si miramos la opción del menú de edición, el botón de la barra de herramientas y el acceso rápidocomo objetos, podremos llegar a la conclusión que ellos, aun siendo objetos distintos, realizan la misma funcionalidad. En otras palabras, estos objetos invocan la misma acción. Siguiendo la conclusión anterior y analizando ahora la funcionalidad de rehacer o deshacer que implementa el editor, nos damos cuenta que estas funciones se basan en acciones, sin importar el objeto que las realizó. Veamosentonces, desde la perspectiva de diseñadores de software, cómo implementar lo anteriormente visto. Primero, podemos pensar que cada acción esté implementada en las múltiples clases que las invocan (botón o menú), pero esto finalmente sería una mala práctica pues haría dependiente las acciones a cada clase y terminaríamos escribiendo acciones iguales (cortar el texto) en elementos distintos (botóno menú).

Sería mejor si lograr independizar las acciones de las clases que las invocan, de esta manera podemos conseguir que: • Un objeto pueda desencadenar una acción
• •

Múltiples objetos puedan desencadenar la misma acción Un objeto pueda encapsular múltiples acciones El problema anterior lo resolvemos implementando una interfaz (Command) común para todas las acciones. Como ya sabemos,una clase que implementa una interfaz es independiente al objeto que la utiliza. El hecho de poder encapsular las acciones en objetos (ConcreteCommand), nos da la ventaja que las acciones puedan implementar herencia o formar grupos de objetos que realicen un conjunto de acciones comunes (macros). Otro de los problemas resuelto con este diseño son las operaciones de rehacer o deshacer, ya quepodemos colocar los objetos Command en una estructura de datos que nos permita mantener una historia de las acciones realizadas. Consideraciones 1. Independizar la parte de la aplicación que invoca las acciones de la implementación de las mismas. 2. Tratar a los comandos como objetos. 3. Proporcionar una interfaz común para todas las acciones. Solución Toda la funcionalidad anterior describe laaplicación del patrón Command, el cual, nos muestra una manera de encapsular una petición. El patrón, dicta una forma para publicar una interfaz común que nos permita, desde el cliente, manejar diferentes acciones sin conocer la acción en sí que será realizada, además, actúa como un escudo que permite separar al cliente de la implementación de las diferentes peticiones. Un Comando (Command) puede...