Diseo de Software con Patrones (parte 3)

Fecha de creacin: 16.08.2001

Revisin 1.0.2 (25.11.2002)

Alberto Molpeceres (al AT javahispano DOT org)

http://www.javaHispano.org

Copyright (c) 2002, Alberto Molpeceres. Este documento puede ser distribuido solo bajo los
trminos y condiciones de la licencia de Documentacin de javaHispano v1.0 o posterior (la ltima
versin se encuentra en http://www.javahispano.org/licencias/).
 Diseo de Software con Patrones (parte 3)

Diseo de Software con Patrones (parte 3)

En el captulo anterior[1] comentamos lo que son los patrones de creaccin y
discutimos los patrones creador y factora, que unidos con el patrn Singleton
(tambin un patrn de creaccin) del primer captulo[2] , se pueden considerar
como los patrones de creaccin bsicos. En ste artculo terminaremos con los
patrones de creaccin comentando tres ms (factora abstracta, constructor y
prototipo), aunque quizs de forma ms superficial que los anteriores.

El patrn factora abstracta (Abstract factory pattern,

GoF).
Este patrn es muy sencillo si se ha entendido el patrn factora[1]. Como la palabra
abstacta nos puede hacer suponer, este patrn lleva al de la factora un punto ms lejos
en la idea de abstraer el cdigo de creaccin de obejtos del resto de la aplicacin. Cmo
debemos entender esto?, pues una factora abstracta es una clase (factora como las del
artculo anterior) pero que los objetos que devuelve son a su vez factoras. Por este
motivo, para que sea efectiva, estas factoras que devuelve, deben ser de la misma
familia (es decir, tener antecesores comnes), como ocurra con las factoras normales.
Como todo se entiende mejor con un ejemplo, pasaremos a un caso claro de la
utilizacin de factoras: los distintos look&feel de Java.
En Java podemos tener el mismo programa con distintos aspectos cambiando solo una
lnea de cdigo, la que se encarga de indicar el look&feel (en estos momentos los
estndar son Metal, Motif y Windows) que queremos utilizar. Esto es posible gracias a que
la clase UIManager de Java es una factora abstracta que genera factoras de
componentes visuales. As , cuando creamos un componente visual para nuestra interfaz
de usuario, Java acude al look&feel seleccionado, que como hemos dicho es una fctora,
y le pide el componente escogido con el aspecto que corresponda.
Supongo que entendiendo el patrn de la factora un ejemplo de cdigo sobre la
factora abstracta es innecesario, por lo que me lo saltar, pero si ha alguin no le ha
quedado claro ya sabe donde tiene que preguntar sus dudas.
La ventaja que obtenemos del uso de este patrn esta en la posibilidad de ampliar la
funcionalidad de la aplicacin con solo aadir una nueva familia (lease factora) de
elementos y un mnimo retoque de la aplicacin (para llevar a cabo la integracin de esa
familia). Aunque esto puede dejar de ser sencillo si, como en el caso de las familias de
componentes visuales, una familia se compone de cientos de elementos.

El patrn constructor (Builder pattern, GoF).

El patrn constructor sigue la misma idea que el patrn factora, pero no se encarga
simplemente de devolver una clase, si no de construir una composicin de objetos entera,
por compleja o sencilla que sea. El caso ms habitual es el de construir una interfaz de
usuario, pero no se limita nicamente a componentes visuales.
Un ejemplo podra ser , siguiendo con el ftbol del captulo anterior, la pantalla que
muestra los datos de un jugador. Podramos hacerlo de forma que mostrase la misma
informacin para todos los jugadores, pero a nadie se le escapa que no es lo mismo un

Pgina 2
 Diseo de Software con Patrones (parte 3)

portero que un delantero, al menos por ningn portero se pagan 10.000 millones ;-). Ya
sea porque le dejamos al usuario configurarlo, o porque nosotros lo hemos codificado as,
resulta poco til, al menos normalmente, saber cuantos goles a metido un portero (si, no
soy un fantico futbolero pero conozco a Chilavert ;-) ), lo mismo que cuantas paradas ha
hecho un delantero. Lo habitual es que esos datos sean 0 permanentemente, es decir, no
aportan nada.
Ok, pasemos a implementarlo. Lo digo entre comillas porque no lo har entero, claro
esta. Primero supongamos la clase Jugador con los datos bsicos, como nombre, edad,
equipo, etc.

public class Jugador

{
private String nombre;
private int edad;
private Equipo equipo;
. . .
}

Y ahora supongamos las subclases de Jugador, aqui por ejemplo, Delantero (con el
resto de tipos de jugadores sera lo mismo), con toda la informacin que queramos sobre
su rendmiento:

public class Delantero extends Jugador

{
private int goles = 0;
private int remates = 0;
. . .
}

Estas son las clases del negocio. Las clases que tienen la informacin que interesa en
nuestra aplicacin. Por supuesto faltan muchas ms, pero en fin, yo no estoy haciendo un
clnico open source del (difunto) PCFtbol ;-).
Ahora pasemos a las clases que manejan la interface de usuario, al menos en la parte
que muestra la informacin de los jugadores.
Primero definiremos una clase abstracta que acte como base de las dems, y que
realice las tareas comnes, como sera mostrar el nombre, la edad, y dems informacin
contenida en la clase Jugador. Aqui tambin podemos poner los controles que
necesitemos para mostrar ms detalles, o cerrar la ventana, o, si como he dicho, estamos
haciendo el clnico del PCFtbol, para poner los botones de despedir o hacer oferta para
gestionar nuestro equipo.

abstract class PanelJugador

{
private JPanel panel;
public PanelJugador (Jugador jug)
{
/*
hacer todo lo que necesitemos para crear la IU,
paneles, botones, etiquetas, etc.
*/
}
abstract public JPanel getIU ();
}

Pgina 3
 Diseo de Software con Patrones (parte 3)

Ahora pasemos a hacer las tareas exclusivas del delantero, es decir, el constructor (el
constructor de su interface, no de su clase) del delantero:

public class PanelDelantero extends PanelJugador

{
public PanelDelantero (Deltantero jug)
{
super (jug);
/*
hacer despues las tareas especificas del delantero.
*/
}
public JPanel getIU ()
{
return (panel);
}
}

Por ltimo nos queda crear una pequea factora que nos devuelva el panel adecuado
al tipo de Jugador que estemos tratando:

public class FactoriaPanelesJugadores

{
public static PanelJugador getPanelJugador (Jugador jug)
{
PanelJugador pj;
if (jug instanceof Delantero)
pj = new PanelDelantero (jug);
if (jug instanceof Defensa)
pj = new PanelDefensa (jug);
if (jug instanceof Centrocampista)
pj = new PanelCentrocampista (jug);
if (jug instanceof Portero)
pj = new PanelPortero (jug);
return (pj);
}
}

Ya lo tenemos hecho, ahora siempre que queramos mostrar la informacin de un

jugador, detallada segn su posicin, lo que tenemos que hacer es simplemente:

PanelJugador pj = FactoriaPanelesJugadores.getPanelJugador (jugador);

y colocar el panel que obtenemos donde queramos (una ventana, un cuadro de dilogo,
una ventana interna, etc) por medio de:

ventana.add (pj.getIU());

Como he dicho antes, tampoco tenemos que tener clases separadas para cada tipo de
jugador, puede ser que tengamos una clase Jugador con todos los atributos, y luego, que
una de las opciones del programa fuera dejarle al usuario definir que datos mostrar de
cada tipo. En ese caso, el dato diferencial sera la posicin del jugador, que indicara que
instancia tomar de la clase que contuviera la informacin sobre que datos mostrar para
esa posicin.

Pgina 4
 Diseo de Software con Patrones (parte 3)

Este ejemplo es ampliable, por ejemplo, usando nuevos parametros que indiquen si
estamos en modo de edicin o no, para determinar si mostramos botones para guardar
los datos o cancelar los cambios, o para saber si mostramos la informacin en etiquetas o
cajas de texto.
A su vez, este patrn es aplicable no slo a distintas clases de datos, como tipo de
jugador o tipo de vehculo (no es lo mismo un coche que un camin), si no que tambin
puede aplicarse a una misma clase en funcin de la cantidad de informacin que
tengamos. Por ejemplo, si tenemos que seleccionar varios valores de una lista de
elementos, si son pocos elementos, podemos ofrecer una serie de checkbox, pero si son
muchos mejor una lista con posibilidad de multiseleccin.
La idea principal de este patrn es la de separar lo ms posible los datos de su
representacin, y para eso Java es un lenguaje ms que apropiado. Podemos variar la
representacin de los objetos segn nos interese, sin tener que tocar las clases que
almacenan los datos.
Adems, cada constructor es independiente de los dems, as que un cambio en la
representacin de los porteros, o de la clase base Jugador, no afecta en nada a las
dems.

El patrn prototipo (Prototype pattern, GoF).

Este patrn se usa en los casos en los que crear una instancia de una clase sea un
proceso muy complejo y requiera mucho tiempo. Lo que hace es crear una instancia
original, y, cuando necesitemos otra, en lugar de volver a crearla, copiar esa original y
modificarla de acuerdo a las indicaciones de la nueva peticin.
Un ejemplo... , podra ser un listado de una base de datos, un listado muy muy largo,
qu tal con 1.000 objetos?. Bien, puede ocurrir que queramos mostrar ese listado en dos
ventanas, ordenado por distintos criterios, para comprobar algn detalle. Qu no sale
mejor?, leer de nuevo la base de datos entera o hacer una copia de la primera lectura y
ordenadrla?. Obviamente lo ms adecuado es la segunda opcin.
Ahora no me voy a meter como ordenar los datos en Java, pero os puedo decir que si
alguna vez lo teneis que hacer os mireis la clase Comparator y el interface Comparable.
Solo dir como hacer la copia de los datos (en realidad javaHispano ya tiene un artculo al
respecto [3]).
La primera opcin es implementar el interface Clonable y usarlo segn nuestra
necesidades, quizs sobreescribiendolo para que devuelva una instancia de nuestra clase
que contiene todos los elementos en lugar de una de la clase Object.
Pero hay que tener en cuenta que esto no siempre es aceptable, porque Clone hace
una copia de las referencias, eso si, pero referencia a los mismos objetos en memoria, por
lo que habr que realmente reescribirla para que haga una copia real de los objetos, la
forma ms rpida sera hacindolo por medio del interface Serializable, pero eso no
tiene mucho que ver con los patrones y si con Java practico, as que tendres que esperar
a otro artculo sobre el asunto (tambin existe ya[4]). Yo, hoy, lo dejo aqu.

Conclusin
Con esto hemos acabado con los patrones de creaccin fundamentales, no son los
nicos y quizs no los mejores, pero recordar que los patrones solo son soluciones

Pgina 5
 Diseo de Software con Patrones (parte 3)

aceptadas como buenas a problemas comnes, una forma de hacer software los ms
reusable, adaptable, ampliable, y consistente posible, pero como en todo, para gustos los
colores.
En el prximo artculo, empezaremos con otro tipo de patrones, los estructurales.
Espero que llegue pronto, aunque quizs me dedique ms a escribir sobre Java y menos
sobre estas cosas que no se si interesan.

Recursos y referencias
[1] Diseo de Software con Patrones (parte 2), http://www.javahispano.org/articulos/ver_articulo.jsp?id=20
[2] Diseo de Software con Patrones (parte 1), http://www.javahispano.org/articulos/ver_articulo.jsp?id=4
[3] Como ordenar colecciones de objetos, http://www.javahispano.org/articulos/ver_articulo.jsp?id=51
[4] Serializacin en Java, http://www.javahispano.org/articulos/ver_articulo.jsp?id=34

Acerca del autor

Alberto es ahora mismo desarrollador de aplicaciones en mbito cliente/servidor para la
empresa T-Systems - debis Systemhaus en Munich (Alemania). Cuando no est
trabajando o "metiendo caa" al resto de los integrantes de javaHispano intenta pasear
con su novia, buscar la desaparecida lgica del idioma alemn o intentar olvidar la
pesadilla que es buscar piso en Munich.

Copyright (c) 2002, Alberto Molpeceres. Este documento puede ser distribuido solo bajo los
trminos y condiciones de la licencia de Documentacin de javaHispano v1.0 o posterior (la ltima
versin se encuentra en http://www.javahispano.org/licencias/).

Pgina 6