Sesion01 Apuntes

Tema 1: Introducción a los patrones de
diseño
Índice
1 Por qué patrones.................................................................................................................2
2 Algunos patrones................................................................................................................3
2.1 Facade............................................................................................................................3
2.2 Adapter.......................................................................................................................... 5
2.3 Singleton........................................................................................................................9
2.4 Proxy............................................................................................................................11
3 Patrones J2EE.................................................................................................................. 12
Copyright © 2005 Depto. CCIA All rights reserved.

Tema 1: Introducción a los patrones de diseño
Aunque cada aplicación J2EE tiene peculiaridades que la hacen única, en el proceso de
desarrollo de casi todas las aplicaciones es necesario solucionar una y otra vez los mismos
problemas: autentificación del cliente, persistencia de datos, separación entre presentación,
lógica y control,... En lugar de reinventar continuamente la rueda, es mucho más productivo
aplicar estrategias que ya hayan funcionado con anterioridad. Esta idea es la que lleva a la
definición de los patrones software.
1. Por qué patrones
En ingeniería del software, un patrón (pattern) es una solución ya probada y aplicable a un

problema que se presenta una y otra vez en el desarrollo de distintas aplicaciones y en
distintos contextos. Es importante destacar que un patrón no es en general una solución en
forma de código directamente "listo para usar", sino más bien una descripción de cómo
resolver el problema y de ante qué circunstancias es aplicable.
Los patrones software fueron popularizados en el libro Design Patterns: Elements of
Reusable Object-Oriented Software, que trata de patrones genéricos, aplicables a una amplia
gama de contextos y a cualquier lenguaje orientado a objetos. Este libro popularizó el
"movimiento" de patrones y se ha convertido en un clásico, ampliamente referenciado y que
muchos han tomado como base para añadir patrones nuevos. Los autores de Design
Patterns... son Erich Gamma, Richard Helm, Ralph Johnson y John Vissides, aunque de
manera jocosa y popular son más conocidos como el Gang of Four. De hecho, en muchas
publicaciones serias los patrones que aparecen en Design Patterns se referencian con las
siglas GoF.
Los patrones J2EE están orientados específicamente a los problemas comunes a todas las
aplicaciones J2EE. Algunos están basados en los patrones originales mientras que otros son
más específicos del tipo de problemas que surgen específicamente en J2EE, bien sea por los
tipos de aplicaciones que se suelen desarrollar con la plataforma o por las características (o
deficiencias, incluso) de la tecnología. Los primeros fueron publicados en el libro Core J2EE
Patterns, convertido también en un clásico dentro del "mundillo" J2EE. En la actualidad son
muchos los libros y los sitios web dedicados íntegramente a patrones para aplicaciones J2EE
o con algún apartado sobre ellos.
Ante todo este floreciente movimiento en torno a los patrones cabe preguntarse si realmente
aportan beneficios. Se suele argumentar que los patrones ofrecen tres ventajas
fundamentales:
• Están ya probados: son soluciones que han sido utilizadas con anterioridad de manera
repetida y se ha comprobado que funcionan.
• Son reutilizables: corresponden con problemas que no son específicos de un caso
2
concreto, sino que se presentan una y otra vez en distintas aplicaciones.

• Son expresivos: cuando un equipo de desarrolladores tiene un vocabulario común de
patrones, se puede comunicar de manera fluida y precisa las ideas fundamentales sobre
el diseño de una aplicación.
Por supuesto, los patrones no pueden ser la solución a todos los problemas de diseño y
desarrollo de aplicaciones J2EE. Como cualquier herramienta o metodología son susceptibles
de malos usos, y abusos ("uso compulsivo" simplemente "porque son buenos". La
experiencia y el sentido común dictarán cuándo son apropiados y cómo utilizarlos.
2. Algunos patrones
En la referencia original del GoF se incluyen 23 patrones fundamentales. Evidentemente no

es posible abordarlos todos aquí, de modo que se ha optado por describir solo algunos de
ellos. El criterio de inclusión no ha sido su importancia per se, sino el hecho de que exista
algún patrón J2EE directamente relacionado o basado en ellos.
2.1. Facade
Supongamos que tenemos un sistema complejo, que agrupa multitud de clases, y para
realizar una tarea tenemos que llamar a varios métodos de estas clases en una secuencia
precisa. Por ejemplo, supongamos un sistema domótico en el que tenemos el siguiente
diagrama de clases
Sistema domótico inicial

Imaginémonos las operaciones que hay que realizar al entrar en casa: hay que desactivar la
alarma, poner el aire acondicionado a nuestra temperatura preferida, y encender las luces.
3
Esto se podría hacer con un código similar al siguiente:
...
//de alguna forma, ya hemos obtenido una referencia a la alarma,
configuración, aire y luces
//y tenemos también el nombre de usuario y el password
...
//desactivar la alarma
alarma.desactivar(password);
//obtener preferencias de usuario
Preferencias prefs = configuracion.getPreferencias(usuario);
//poner el aire acondicionado a la temperatura deseada
Float temp = (Float) prefs.getPreferencia("temperatura");
aire.setTemp(temp.floatValue());
//poner las luces en "auto" si es la preferencia del usuario
String luces = (String) prefs.getPreferencia("luces");
if (luces.equals("auto"))
luces.setAuto(true);
...
Como se ve, una operación tan sencilla en apariencia implica manejar un número elevado de
objetos y métodos. salirDeCasa() sería igual de tedioso: apagar las luces, el aire, activar
la alarma.... Un cliente que quiera invocar una de estas operaciones no debería contener todo
este código. Parece inmediata la idea de crear una clase a la que trasladaremos todo este
código y a la cual puedan acceder los clientes que lo necesiten. Esto es ni más ni menos que
un facade.
Patrón facade
Un Facade (fachada) consiste en implementar un interfaz simplificado para un sistema
complejo. La idea es implementar una clase con un interfaz sencillo y que encapsule los
4
detalles de la interacción entre todas las clases del sistema. Es importante notar que se sigue
permitiendo el acceso directo a las clases del sistema a los clientes que necesiten "acceso a
bajo nivel" pero se simplifica la interacción para los que no necesiten más que operaciones
comunes.
En aplicaciones J2EE, las fachadas se suelen utilizar para proporcionar un "frontal de
servicios" de la capa de negocio. De este modo, la interacción de los clientes (web, swing,
etc...) con esta capa se simplifica considerablemente. Como veremos en el tema 3, en
aplicaciones distribuidas las fachadas también mejoran la eficiencia del sistema, ya que las
operaciones "de fachada para adentro" serán todas locales y la única llamada remota será la
del cliente a la fachada.
2.2. Adapter
Supongamos que tenemos un código que es cliente de otra clase. Por ejemplo, un código que
realiza operaciones con una librería de matrices:
...
Matrix prod = a.mult(b);
System.out.println("Fila 1, columna 2:" + prod.get(1,2));
System.out.println("El determinante es: " + prod.determinante());
...
Supongamos también, para simplificar la discusión que sigue, que Matrix no es una clase
concreta, sino un interfaz. La librería nos proporciona distintas clases (MatrixInt,
MatrixFloat, ...) que implementan dicha interfaz, para que usemos la más apropiada.
Por motivos fuera de nuestro control (nueva versión del sistema, pérdida de los derechos de
uso del software...) en un momento dado desaparece la posibilidad de seguir usando dicha
librería. En su lugar conseguimos una nueva clase que implementa más o menos las mismas
operaciones que la antigua pero (como era de esperar) no tiene el mismo interfaz. En
concreto, en nuestro caso se dan las siguientes diferencias:
• La nueva clase se llama MatrixNew
• La multiplicacion es un método estático de la clase MatrixNew, que acepta como
parámetros los dos operandos y devuelve el resultado (recordemos que antes era un
método propio del primer operando)
• El método get sigue existiendo, incluso con los mismos parámetros, pero ahora genera
una excepcion IndexOutOfRangeException si nos salimos de la matriz. Con la
librería anterior saber si nos salíamos era responsabilidad del programador, en caso de
salirnos la documentación decía que se devolvería -1.
• El método determinante() funciona exactamente igual (algo es algo).
Necesitamos por tanto poder seguir usando nuestro código cliente antiguo, con las menores
5
modificaciones posibles, con nuestra nueva librería. En terminología de patrones, lo que

buscamos es un adapter, una clase que convierte un interfaz a otro que necesita un cliente.
Existen dos formas de implementar un adapter, una basada en composición y otra en
herencia. El primer método se llama object adapter y el segundo class adapter. Cada uno
tiene sus ventajas e inconvenientes, como se verá a continuación.
2.2.1. Object adapter
En este caso el adaptador contiene o envuelve el objeto que deseamos adaptar. En nuestro
ejemplo de la librería de matrices el código podría ser algo como:
public class MatrixNewAdapter implements Matrix {

//aqui tenemos el objeto adaptado. A él le redirigiremos las peticiones
del cliente, convenientemente modificadas
private MatrixNew adaptado;
//en el constructor pasamos el objeto adaptado
public MatrixNewAdapter(MatrixNew mn) {
adaptado = mn;
}
//para multiplicar llamamos ahora al metodo estatico de MatrixNew.
Necesitamos
//construir un MatrixNew a partir de un Matrix y viceversa
public Matrix mult(Matrix m) {
MatrixNew mn = MatrixNew.mult(adaptado, construyeMatrixNew(m));
return new MatrixNewAdapter(mn);
}
//escondemos al cliente la excepción, cambiándola por -1, que es lo que
devolvía la librería antigua
public double get(int fila, int col) {
try {
return adaptado.get(fila,col);
}
catch(IndexOutOfRangeException e) {
return -1;
}
}
//aunque este método es exactamente igual, nos vemos obligados a
"reescribirlo"
public double determinante() {
return adaptado.determinante();
}
//este es un método auxiliar que debería construir un objeto MatrixNew
copia de un Matrix
public MatrixNew construyeMatrixNew(Matrix m) {
...
...
}
}
6
Por tanto, un antiguo código que podía ser
Matrix a = new MatrixDouble(3,3);

Matrix b = new MatrixDouble(3,3);
...
Matrix c = a.mult(b);
double valor = c.get(1,1);
double det = c.determinante();
Cambiará únicamente en la parte de instanciación de objetos.
Matrix a = new MatrixAdapter(new MatrixNew(3,3));

Matrix b = new MatrixAdapter(new MatrixNew(3,3));
Aunque cambia algo del código del cliente, es mucho más flexible cambiar únicamente los
new que tener que cambiar todas las referencias a los objetos y métodos de las clases
antiguas (en un código más realista habría muchas más de estas últimas que new).
El diagrama de clases genérico sería el siguiente
Patrón adapter
El adaptador implementa el interfaz al que llama el cliente. El cliente llama al adaptador, sin
saber que es tal cosa (lo único que sabe es que proporciona las operaciones que necesita) y
éste transforma las peticiones de manera que puedan ser procesadas por el objeto adaptado.
Esta forma de implementar los adaptadores permite no solo adaptar la clase original, sino
también cualquiera de sus subclases. Por el contrario, es más tedioso de escribir porque hay
que implementar todos los métodos del adaptado, aunque en el adaptado y en la nueva clase
funcionen exactamente igual (un ejemplo es el método determinante() de nuestra clase
MatrixNewAdapter, que se limita a "pasarle la pelota" a MatrixNew sin más cambios).
2.2.2. Class adapter
Con esta estrategia de implementación el adaptador hereda de la nueva clase, con lo cual
obtiene todos sus métodos públicos o protegidos, que ya no habrá que reescribir (recordemos
determinante()). Además debe implementar el antiguo interfaz. En lenguajes de
herencia múltiple, como C++, no importa que el antiguo interfaz sea en realidad una clase,
7
porque se puede heredar de ella y también de la clase adaptada. En java, al menos uno de los
dos tiene que ser un interface para que se pueda extender uno e implementar el otro.
El código para nuestro ejemplo de matrices quedaría como sigue:
//heredamos de la clase adaptada e implementamos el interfaz objetivo

public class MatrixNewAdapterClass extends MatrixNew implements Matrix {
//para multiplicar llamamos ahora al metodo estatico de MatrixNew.
Necesitamos
//construir un MatrixNew a partir de un Matrix y viceversa
public Matrix mult(Matrix m) {
return MatrixNew.mult(this, construyeMatrixNew(m));
}
//escondemos al cliente la excepción, cambiándola por -1, que es lo que
devolvía la librería antigua
public double get(int fila, int col) {
try {
return get(fila,col);
}
catch(Exception e) {
return -1;
}
}
//este es un método auxiliar que debería construir un objeto MatrixNew
copia de un Matrix
public MatrixNew construyeMatrixNew(Matrix m) {
...
}
}
La diferencia básica estriba en que ahora se hereda de la clase adaptada (lo que proporciona
una especie de "redireccion automática" de todas las peticiones que ya implementaba la clase
base) y por tanto no hace falta guardar ninguna instancia de dicha clase ni reimplementar los
métodos que sean iguales. Como contrapartida, como se hereda de una clase concreta, las
subclases de esa ya no quedarán automáticamente adaptadas.
El diagrama genérico para un class adapter es el siguiente:
Patrón adapter. Implementación con class adapter
8
En aplicaciones J2EE, se suele utilizar este patrón para proteger a los clientes (web, swing,
...) de los cambios en el interfaz de la capa de negocio. En este caso, el patrón J2EE que
suele cumplir las funciones de adapter es el conocido como Business Delegate.
2.3. Singleton
Hay muchos casos en los que solo necesitamos una instancia de una determinada clase.
Ejemplos típicos son clases que representan las preferencias del usuario o la configuración
del sistema, o clases que sirven de interfaz con dispositivos físicos.
En estos casos hay que asegurarse de poder obtener una referencia a dicha instancia desde
cualquier punto del código, y que solo haya una instancia creada, para evitar posibles
problemas o inconsistencias. Una posible solución es definir variables globales (o sea,
static), pero esto tiene dos problemas:
• Por descuido, se podría instanciar una misma variable en dos sitios distintos, lo que
"machacaría" el valor anterior.
• El orden y momento de inicialización de las variables depende del compilador, lo cual
puede ser delicado si unas dependen de otras y están en lugares distintos.
El patrón singleton nos permite asegurar que de una clase habrá solo una instancia, y
proporciona un punto de acceso a ella global a todo el código. El diagrama de clases es muy
sencillo, ya que se compone de una única clase:
Patrón singleton
El método getInstance() nos sirve para obtener la referencia a la única instancia de la
clase. Además dicha instancia está almacenada dentro de la propia clase como una variable
de tipo static (esto último puede resultar curioso, pero no deja de ser un "truco ingenioso"
perfectamente legal para el compilador). Por supuesto el singleton tendrá otros métodos, los
servicios que proporcione la clase.
La implementación de un singleton podría hacerse de varias formas, pero casi siempre se
utiliza el mismo tipo de código. Vamos a resumir las ideas que nos llevarán a la
implementación final:
• Si el constructor de una clase es público, podrá llamarse desde cualquier otra. Por tanto,
si queremos asegurar un control de la creación de instancias, no podemos tener un
constructor público, debemos hacerlo privado:
9
public class MiSingleton {

private MiSingleton() {
//aqui va el codigo del constructor
}
}
• Evidentemente, aunque el código anterior sea una definición legal que compilará
perfectamente, no parece tener mucho sentido. Si el constructor es privado, solo se podrá
llamar desde un objeto de la clase MiSingleton. Pero ¡no podemos instanciar objetos
de esa clase, porque el constructor es privado!. La solución al aparente dilema consiste en
utilizar un método estático para llamar al constructor:
}
public static MiSingleton getInstance() {
return new MiSingleton();
}
}
//código aparte...
MiSingleton ms = MiSingleton.getInstance();
• Con esto ya conseguimos controlar el acceso al constructor y poder llamarlo desde fuera
de la clase. Lo único que nos falta es asegurarnos de que en todo momento existe una
única instancia de MiSingleton. El "truco" consise en almacenar dicha instancia
dentro de la propia clase MiSingleton (como una variable static) y en introducir
código en getInstance que chequee si dicha instancia está creada o no, para
devolverla o en caso contrario devolver un nuevo MiSingleton.
//la unica instancia que existe de esta clase
private static MiSingleton unico = null;
}
public static MiSingleton getInstance() {
//instanciar el singleton si no existe
if (unico == null) {
unico = new MiSingleton();
}
//devolver el singleton
return unico;
}
}
//código aparte...
MiSingleton ms = MiSingleton.getInstance();
Como puede verse, este código es una especie de "idea feliz" que consigue de forma elegante
10
el objetivo que nos proponíamos. Aunque quizá esto podría conseguirse de otras formas, esta
es ampliamente utilizada y conocida, por lo que merece la pena usarla en lugar de intentar
formas propias de hacerlo (después de todo, esta "reutilización de ideas" es consustancial a la
idea misma de patrones software).
En aplicaciones J2EE, el uso típico de este patrón es para implementar un encargado global
de localizar recursos JNDI como conexiones JDBC, EJBs, etc. Esto es lo que se conoce como
Service Locator.
2.4. Proxy
En el mundo real, las personas demasiado importantes u ocupadas (directivos, estrellas

mediáticas,...) no suelen tener una interacción directa con la gente que requiere sus servicios,
sino que ésta se hace a través de un "intermediario" (que puede tomar diversas formas: un
asistente, un representante, un apoderado,...).
En una aplicación, un proxy sería un objeto que actúa "en representación" de otro. El cliente,
en lugar de interactuar directamente con el objeto, interactúa con el proxy y éste le pasa al
objeto las peticiones del cliente (convenientemente filtradas, modificadas,...). Los motivos
por los que se puede usar un proxy son variados: por ejemplo, la necesidad de "proteger" al
objeto verificando que el cliente tiene permiso para acceder a los métodos o bien hacer que
éste no tenga que "preocuparse" de que el objeto se encuentra en otra máquina. Nótese que
este es el tipo de servicios que proporciona un contenedor de EJBs cuando interactuamos con
los mismos.
El diagrama de clases de un proxy típico se muestra en la figura siguiente.
Patrón proxy
Como se ve en el diagrama, el cliente necesita acceder a alguna clase que implemente un
determinado Servicio. El proxy implementa este interfaz pero en realidad no realiza las
operaciones sino que las delega en ServicioReal, un objeto que sí es capaz de realizar
las operaciones. El proxy puede utilizar esta intermediación para chequear permisos de
acceso, acceder a un ServicioReal remoto de manera transparente para el cliente o bien
controlar su creación y destrucción si es un objeto que consume muchos recursos.
11
En aplicaciones J2EE, el uso típico de este patrón es para ocultar a los clientes que la capa
de negocio es remota. En este caso, el que cumpliría las funciones de proxy sería el "punto de
entrada" a la capa de negocio, que como veremos es el llamado Business Delegate. Por
supuesto, como ya se ha comentado siempre que estamos utilizando un EJB estamos
haciendo uso de proxies, pero en este caso ya no son patrones que debamos implementar
nosotros, sino algo gestionado por el contenedor.
3. Patrones J2EE
Como se ha comentado, en el libro Core J2EE Patterns se encuentra el catálogo de patrones

que se suelen considerar como "patrones básicos" en el mundo J2EE. Una versión resumida
del catálogo está disponible en su sitio web. Siguiendo la idea de dividir la arquitectura de
una aplicación en varias capas, los patrones se clasifican atendiendo a la capa a la que
pertenecen. En la figura 5 aparece el esquema general en la que se muestra la situación de
cada uno de los 21 patrones en el modelo de capas y las relaciones que existen entre ellos.
Iremos viendo con detalle algunos de estos patrones y sus relaciones en los distintos temas
del módulo.
12
Catálogo de patrones de Core J2EE Patterns
13
14

Sesion01 Apuntes

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sesion01 Apuntes

Cargado por

Copyright:

Formatos disponibles

Tema 1: Introducción a los patrones de

Copyright © 2005 Depto. CCIA All rights reserved.

1. Por qué patrones

En ingeniería del software, un patrón (pattern) es una solución ya probada y aplicable a un

concreto, sino que se presentan una y otra vez en distintas aplicaciones.

En la referencia original del GoF se incluyen 23 patrones fundamentales. Evidentemente no

Sistema domótico inicial

Esto se podría hacer con un código similar al siguiente:

modificaciones posibles, con nuestra nueva librería. En terminología de patrones, lo que

2.2.1. Object adapter

public class MatrixNewAdapter implements Matrix {

Por tanto, un antiguo código que podía ser

Matrix a = new MatrixDouble(3,3);

Matrix a = new MatrixAdapter(new MatrixNew(3,3));

2.2.2. Class adapter

//heredamos de la clase adaptada e implementamos el interfaz objetivo

Patrón adapter. Implementación con class adapter

public class MiSingleton {

En el mundo real, las personas demasiado importantes u ocupadas (directivos, estrellas

Como se ha comentado, en el libro Core J2EE Patterns se encuentra el catálogo de patrones

Catálogo de patrones de Core J2EE Patterns

También podría gustarte