Command y Unit of Work

posted on 01/10/2015 by mrocabado@mindwaresrl.com | Leave your thoughts

Command
Este patrón encapsula la solicitud para ejecutar una tarea como un objeto de manera tal que el
componente que solicita la ejecución (Invoker o Actor) desconoce los detalles y dependencias
necesarias para ejecutar la tarea ( Command o Acción). Una vez que el comando se crea y se
asigna al Invoker, el Invoker puede solicitar la ejecución del Command en otro momento y no
necesariamente en el momento en el que se crea un Command.

Cuando se crea una instancia de una clase que implementa la interfaz Command se le

proporciona el(los) objeto(s) necesarios para ejecutar el comando ( Receiver(s)). Es decir,  una
vez creado el Command, éste incluye todas las dependencias necesarias para ejecutar la acción
o tarea (esto es una consecuencia de que el/los método(s) en la interfaz Command no incluyen
parámetros).
Entonces, el patrón permite la ejecución de una tarea de manera tal que los siguientes
aspectos quedan separados:

 La solicitud de ejecución de una Acción realizada por un Actor vs. de la ejecución de la

Acción.

 La creación de la solicitud de ejecución de una Acción vs. el momento en el que

efectivamente se ejecuta.

Unit of Work
Este patrón tiene como objetivo consolidar aquellos objetos nuevos, modificados o eliminados
en un proceso de negocio de manera tal que todos los cambios pendientes en el repositorio de
datos se realicen como una unidad.

Algunos frameworks de persistencia ya incorporan este patrón en los mecanismos que

proveen; por ejemplo, una instancia que implementa la interfaz EntityManager de un proveedor
JPA hace un seguimiento a los cambios realizados en las entidades que gestiona para generar
un serie de sentencias SQL que permiten sincronizar el estado de los objetos con la BD
relacional.
Finalmente, se trata de una aplicación del patrón Command donde las tareas (Commit y
Rollback) y  las dependencias para realizarla están explícitamente definidas.

Referencias
[1] Design Patterns: Elements of Reusable Object-Oriented Software
[2] Unit of Work
[3] Unit of Work: Ejemplo

State
posted on 02/10/2015 by mrocabado@mindwaresrl.com | Leave your thoughts

State
El propósito de este patrón de diseño es facilitar que un objeto cambie su comportamiento
cuando se realizan cambios en su estado interno.

La idea es evitar los problemas asociados a este estilo de código:

En el anterior código se evidencia que el método delete()  se comporta de manera diferente

dependiendo de si el estado actual se encuentra en alguno de cuatro posibles valores:
“Proposed”, “Active”, “Resolved” o “Closed”. Un diseño como este presenta al menos los
siguientes problemas:
 Es necesario cambiar el método cuando se aumenten nuevos estados en una clara
violación de principio Abierto/Cerrado (OCP)

 El método realiza más de una tarea, una tarea por cada estado.

 La lógica de negocio vinculada a un estado está dispersa en varios métodos.

Si la clase tiene varios métodos con una estructura similar, el esfuerzo necesario para
agregar/eliminar estados se incrementa rápidamente haciendo que el software sea difícil de
cambiar (rigidez)

La estructura general del este patrón de diseño es la siguiente:

Entonces, en lugar de emplear una sentencia condicional para determinar el comportamiento,

la ejecución se delega a un objeto que representa el estado en el que actualmente se encuentra
la entidad (Context). El objeto que representa el estado opera con la entidad y si es necesario
cambia el objeto que representa el estado de la entidad. De esta manera, la siguiente vez que
esta entidad reciba una llamada al mismo método, ésta será delegada a otro objeto (estado).
Referencias
[1] Design Patterns: Elements of Reusable Object-Oriented Software
Decorator y Proxy
posted on 06/10/2015 by mrocabado@mindwaresrl.com | Leave your thoughts

Decorator
El propósito de este patrón de diseño es facilitar la adición dinámica de nuevas
responsabilidades a un objeto. Es una alternativa al uso de los mecanismos de herencia.

La estructura del patrón es la siguiente:

Tanto el componente original como los decoradores implementan la misma interfaz; de esta
manera, una clase cliente no distingue entre una instancia del componente o una instancia del
decorador.  Los decoradores incluyen una instancia del componente a decorar empleando los
mecanismos de composición y delegación para aumentar las responsabilidades percibidas del
componente decorado de manera tal que tanto para el componente decorado como para el
cliente la presencia del decorador es transparente. Finalmente, el patrón puede aplicarse varias
veces (decorando instancia que a su vez con decoradores) tal cual se demuestra el siguiente
vídeo:

Proxy
El propósito de este patrón de diseño es proveer un sustituto de otro objeto de manera tal que
el sustituto (o proxy) pueda gestionar el acceso al objeto que sustituye.

La estructura del patrón es la siguiente:

De manera muy similar al patrón Decorator, en el patrón Proxy tanto el objeto sustituto (proxy)
como el objeto que es sustituido (RealSubject) implementan la misma interfaz; de la misma
manera,  el objeto sustituto tiene acceso al objeto que sustituye.
La diferencia sustancial entre Proxy y Decorator radica en el propósito de la relación entre el
objeto sustituto y el objeto real. En el caso de Decorator  el propósito de la relación es la
adición dinámica de responsabilidades, en el caso de Proxy el énfasis esta en gestionar el
acceso al objeto real y no en la extensión de su funcionalidad (Proxy es una aplicación
específica de las ideas detrás del patrón Decorator).

Por estas razones, el patrón proxy es muy empleado en la implementación de mecanismos de

acceso a datos y funcionalidad de manera tal que la existencia de los mecanismos sea
trasparente para el cliente: es decir, para el cliente el acceso al sustituto o al objeto real es
idéntico (porque ambos implementan la misma interfaz).

Los escenarios usuales en los que se emplea este patrón son los siguientes:
  Proxy remoto. Este proxy actual como el representante local de un objeto remoto
(residente en otro proceso) ocultando los detalles de los mecanismos de comunicación
con el objeto remoto. (SOAP, RMI son tecnologías que  incluyen este tipo de proxies)
 Proxy virtual. Es un sustituto de objeto real cuyo estado es costoso crear. Con este tipo
de sustitutos es posible gestionar la creación del estado en el objeto real de manera tal
que sólo se cree el estado cuando éste se requiera (una estrategia conocida como
carga diferida o lazy loading). Muchos lenguajes de programación incluyen mecanismos
para generación de objetos sustitutos en tiempo de ejecución.
 Proxy de protección. Donde podemos emplear el proxy para controlar el acceso a objeto
aplicando reglas de control de acceso
Referencias
[1] Design Patterns: Elements of Reusable Object-Oriented Software