Patrón de diseño Proxy

1
31076

PATRÓN DE DISEÑO PROXY

Los
ejemplos de este tutorial están hechos con el siguiente
entorno de desarrollo:

  • Jboss Eclipse
    IDE.

  • JDK 1.5

INTRODUCCIÓN

Desde
hace unos años están apareciendo gran cantidad de
herramientas que introducen nuevos conceptos como la orientación
a aspectos (AOP),  la interceptación, etc… .  En el
fondo, todas ellas están basadas en algo no tan nuevo como es el
patrón Proxy.  Podríamos definir un proxy, como un
objeto que fuerza que todas las llamadas al objeto al que se desea
invocar  pasen previamente a través de él. Esto nos
permite realizar acciones que podríamos llamar transversales a
la funcionalidad realizada por el objeto final invocado, como por
ejemplo, trazabilidad, seguridad, transaccionalidad etc… . Es decir,
si por ejemplo nosotros invocamos al método sayHello del objeto obj de la clase Saludo,
podríamos «interceptar» esa llamada a través del Proxy,
para comprobar si realmente el que invoca al método tiene
permisos para realizar la acción, sin tener que modificar para
ello el método sayHello .
En esto se basan gran cantidad de herramientas como Spring, Acegi, la
arquitectura de EJBs de gran cantidad de servidores de aplicaciones
como JBoss, etc.

Para ello, usaremos la clase java.lang.reflect.Proxy que lleva ya con nosotros desde la versión 1.3 de la J2SE.

Sin más, vamos a realizar un ejemplo sencillo, para demostrar todo esto:

EL EJEMPLO

Nos
crearemos un proyecto nuevo en nuestro Eclipse, y generaremos primero
un Interfaz que denominaremos Manager, que define toda la funcionalidad
que preveemos puede tener la lógica de negocio de las clases de
nuestra aplicación:

Vamos a construir ahora una clase implemente el interfaz:


Vamos ahora a contruir el Manejador o Handler, que será el que
será previamente invocado a los métodos de los managers:

package com.autentia.adictos.proxy;


Ahora crearemos una Factor�a de Managers, que creará los mismos encapsulados dentro de un Proxy:


Creamos una clase para probar lo que hemos hecho:

package com.autentia.adictos.proxy;

Mostremos la salida estándar:

Salida estándar



Como
podéis ver, el código del Handler es invocado previamente
al código del UserManagerImpl. Curioso ¿no?.
 ¿Os suena esto ?. Supongo que si conocías ya el
tema de AOP, AspectJ etc…, verás que se parece
sospechosamente. Ahora, en el manejador podríamos trazar lo que
ocurre, o guardar en base de datos un registro, o autenticar o
autorizar, o abrir una transacción, invocar al método y
cerrar una transacción, etc…  Suponed éste
código:

Creo que esto habla por sí s�lo.

El único problema es que el hacer que nuestros Managers
implementen un interfaz es algo rígido, por eso es mejor usar
frameworks que nos proporcionan todo esto de una manera más
flexible, como Spring, Acegi, EJB 3.0 etc…, pero creo que es
más bonito conocer como se hacen las herramientas o en que se
basan antes de usarlas, y no creer que es magia….

1 Comentario

  1. Excelente ejemplo, muchas gracias. Realmente no está tan obvio, pero tampoco no está difícil nada que no arregle un hora de debuggear.

Dejar respuesta

Please enter your comment!
Please enter your name here