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