Patrón de diseño Proxy

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….







Respuesta (1)

  1. cesar landeta
    octubre 31, 2014 at 2:31 am · Responder

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

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">