SOLO PROGRAMADORES

Introduccin
El movimiento de los patrones de diseo se
encuentra actualmente en auge. Todos los
meses surgen nuevas publicaciones escritas,
artculos digitales y comunidades en la web
que tratan sobre esta disciplina. Adems, al
tratarse de un campo relacionado con la fase
de diseo del software, ste es independiente
del lenguaje de programacin empleado. Los
patrones de diseo pueden ser aplicados en
lenguajes tan dispares como Java, C++, PHP,
Visual Basic, C#, etc.
Un ejemplo de la importancia que estn
tomando los patrones de diseo de software
lo representa el hecho de que la metodologa
de desarrollo METRICA 3, de la Administra-
cin General del Estado, incorpora una tarea
dedicada a la identificacin de patrones (DSI
2.2: Identificacin de Mecanismos Genricos
de Diseo).
En esta entrega de la serie veremos qu son los
patrones de diseo y cules son los patrones de
diseo bsicos, patrones que aparecen con una
gran frecuencia en la prctica. La presentacin
de cada patrn ir acompaado de una explica-
cin terica y de una visin prctica, en la que se
ver su aplicacin con distintos lenguajes de
programacin, lo que nos permitir apreciar
mejor su potencial.
Patrones de diseo: concepto y disciplina
Los patrones de diseo de software son solucio-
nes reutilizables a problemas recurrentes que
aparecen durante el proceso de diseo de soft-
ware orientado a objetos.
Por qu surgen los patrones de diseo? Por la
necesidad de transmitir la experiencia.
Lo que diferencia a un programador brillante y
experto de un programador igualmente brillante
pero inexperto es la experiencia. Conforme un
programador gana experiencia, ste reconoce el
parecido entre los nuevos problemas que van
surgiendo y los problemas que ya ha resuelto con
anterioridad. Incluso cuando tiene ms expe-
riencia, es capaz de reconocer que las soluciones
a estos problemas siguen patrones recurrentes.
Con el conocimiento de estos patrones, los pro-
gramadores expertos son capaces de identificar
las situaciones en las que stos tienen aplica-
cin, y utilizarlos sin tener que detenerse para
analizar el problema y vislumbrar diferentes
estrategias de resolucin.
No obstante, que un programador haya descu-
bierto un determinado patrn no implica que sea
capaz de expresar su conocimiento a otros pro-
gramadores. Aqu es donde aparece la disciplina
de los patrones de diseo. Esta disciplina esta-
blece una especie de especificacin para docu-
mentar los patrones de diseo de software
orientado a objetos. Segn esta especificacin,
todo patrn de diseo debe ir acompaado de:
Nombre del patrn: Gracias a ste nombre
podremos identificar al patrn y referirnos al
mismo cuando discutamos con otros disea-
dores durante la fase de diseo.
Sinopsis: Breve resumen que nos indica la
esencia de la solucin proporcionada por el
patrn. Es de gran utilidad para los progra-
madores expertos que no conocen el nombre
del patrn. De esta forma, se les indica lo que
ste hace.
Contexto: Descripcin detallada del problema
recurrente que el patrn viene a solucionar.
Solucin: Contiene una descripcin detallada
del patrn, y viene acompaada de un diagra-
ma de clases UML que refleja grficamente
esta solucin.
Ejemplo de aplicacin: La descripcin del
patrn siempre ser ms rica si va acompaa-
da de un ejemplo prctico.
No obstante, a lo largo de esta serie de artculos
no emplearemos este formato de documenta-
cin, que, aunque exhaustivo, podra resultar
difcil de seguir.
52
A lo largo de esta serie de artculos
haremos un repaso de los principales
patrones de diseo de software y
veremos cmo llevar a cabo su
implementacin con los lenguajes de
programacin ms populares.
LVARO ZABALA ORDEZ
DISEO
Patrones de diseo:
un curso prctico (I)
Patrones de diseo:
un curso prctico (I)
SOLO PROGRAMADORES
Los orgenes de los patrones de diseo
Antes de entrar en materia, veremos de
forma muy breve los orgenes de los patro-
nes de diseo de software.
El concepto de patrn de diseo procede
del campo de la arquitectura. Los trabajos
del arquitecto Christopher Alexander
(vase referencia [1] del cuadro "Bibliogra-
fa recomendada"), publicados a finales de
la dcada de los 70, postulaban la existen-
cia de patrones repetitivos en las solucio-
nes adoptadas en planeamiento urbanstico
y construccin. Estas ideas eran suscepti-
bles de ser aplicadas a otras disciplinas,
entre ellas, la de la Ingeniera del Software.
As, en el ao 1987 los archiconocidos
W.Cunningham y Kent Beck (padre de la
metodologa "Extreme Programming") uti-
lizaron algunas de las ideas de Alexander
para identificar una serie de patrones en la
construccin de interfaces de usuario
(vase referencia [2] del cuadro
"Bibliografa recomendada"). Estos patro-
nes se emplearon en el lenguaje SmallTalk
(uno de los pioneros de los lenguajes orien-
tados a objetos puros) y dieron lugar al
conocidsimo patrn Modelo/Vista/Con-
trolador.
En el ao 1994 Gamma, Helm, Vlissides y
Jhonson (grupo de autores conocido como
el Gof o "pandilla de los cuatro") publicaron
el libro que es considerado la "biblia" de los
patrones de diseo (vase referencia [3] del
cuadro "Bibliografa recomendada"). Este
libro populariz la idea de los patrones de
diseo e introdujo la clasificacin de patro-
nes de diseo ms extendida en la actuali-
dad. A partir de este momento, se produjo
la explosin del fenmeno de los patrones
de diseo. Se han desarrollado patrones
aplicables a diferentes niveles de la lgica
de la aplicacin, como persistencia, mensa-
jera, presentacin, etc.
El ltimo movimiento parece ser el de los
patrones para la creacin de aplicaciones
empresariales, que tratan de cubrir todos
los aspectos de un sistema empresarial.
En este sentido cabe destacar los trabajos
de Martin Fowler (vase referencia [4] del
cuadro "Bibliografa recomendada"), o las
publicaciones de Sun (vase referencia [5]
del cuadro "Bibliografa recomendada") y
Microsoft (vase referencia [6] del cuadro
"Bibliografa recomendada") para mostrar
cmo construir aplicaciones empresaria-
les con sus plataformas de desarrollo.
Paralela-mente al concepto de patrn, ha
ido surgiendo el concepto de "Antipa-
trn". Se basa en la idea de que con fre-
cuencia resulta ms fcil aprender de los
errores, por lo que se trata de catalogar
los errores ms frecuentes de anlisis,
diseo y programacin.
Clasificacin de los patrones de diseo
Los patrones de diseo varan tanto en su
granularidad como en su nivel de abstrac-
cin. Puesto que existen numerosos patro-
nes de diseo, stos se clasifican en cate-
goras, lo que facilita su aprendizaje y per-
mite referirse a patrones similares median-
te la familia a la que pertenecen.
En la obra del Gof (vase referencia [3] del
cuadro "Bibliografa recomendada") se pro-
ponen las siguientes categoras:
Patrones de creacin: Esta categora
agrupa a los patrones que proporcionan
guas de cmo construir objetos, cuando
su creacin implique la toma de una
decisin. Esta decisin puede ser bsica-
mente elegir qu subclase dentro de una
jerarqua de herencia instanciar, y qu
clase tiene la responsabilidad de su cre-
acin
Patrones estructurales: Los patrones de
esta categora describen mecanismos
genricos para organizar diferentes cla-
ses de objetos entre s.
Patrones de comportamiento: Estos
patrones se utilizan para organizar, ges-
tionar y combinar el comportamiento de
diferentes objetos.
A esta clasificacin, Mark Grand en su
obra "Patterns in Java" (vase referencia
[7] del cuadro "Bibliografa recomenda-
da") aade la categora de "Patrones fun-
damentales". Segn este autor, esta cate-
gora engloba a patrones que aparecen
con mucha frecuencia en el resto de
patrones, de mayor complejidad.
Comenzaremos nuestro repaso de los prin-
cipales patrones de diseo por dos patrones
de esta categora: el patrn Interfaz y el
patrn Delegacin.
El patrn Interfaz
Este patrn prcticamente aparece en el
resto de patrones de diseo que vamos a
ver a lo largo de esta serie de artculos, por
lo que con l nos vamos a detener un poco
ms. Se utiliza cuando deseamos que una
clase que hace uso de los servicios propor-
cionados por otras clases, permanezca
independiente de estas.
Qu ventajas obtenemos con ello? Reduce
el acoplamiento entre clases, y evita la pro-
pagacin de cambios. Y cmo podemos
implementar este patrn? A travs de la
utilizacin de interfaces. Una interfaz defi-
ne un contrato que deben cumplir una serie
de clases, independientemente de los deta-
lles internos de implementacin de cada
una de stas. Se trata por tanto de un tipo
especial de herencia denominado "de inter-
faz". Mediante la aplicacin de este patrn
de diseo, podemos independizar una clase
de otra que le presta servicios, haciendo
que no tenga una referencia a la clase que
ofrece el servicio, sino a la interfaz que
define el contrato del servicio a prestar.
Cmo podemos implementar este patrn
de diseo con algunos de los principales
lenguajes de programacin?
Java y C#, dos de los ltimos en llegar, tie-
nen una construccin de lenguaje denomi-
nada interfaz. En C# podemos definir una
interfaz de la siguiente manera:
interface Educado{
void diHola();
void diAdios();
}
Esta interfaz define un comportamiento,
del que podrn heredar otras clases a
travs de la herencia de interfaz. En el
listado 1 tenemos dos implementaciones
de esta interfaz con C#. En dicho ejemplo
tenemos una interfaz "Educada", que
obliga a que todas las clases que la
implementen tengan mtodos de saludo
y despedida, impresos por consola. La
clase EducadoIngles implementa estos
mtodos en ingls, mientras que la clase
EducadoCastellano en castellano. Las
interfaces en Java son similares.
Supongamos que tenemos una clase
encargada de interactuar con el usuario
en un entorno de lnea de comandos,
saludndolo al iniciar la sesin y despi-
dindose al terminar. Podemos indepen-
dizar nuestra clase del idioma empleado
haciendo que tenga una referencia a la
interfaz educado:
53
DISEO
Patrones de diseo: un curso prctico (I)
Diagrama de clases UML
del patrn Interfaz.
SOLO PROGRAMADORES
class HaceUsoDeEducado{
private Educado educado;
}
En funcin del idioma seleccionado por el usua-
rio, esta clase recibir en su constructor una
implementacin u otra, sin necesidad de modifi-
car la clase que hace uso de los servicios ofreci-
dos por esta interfaz. Es ms: podemos seguir
aadiendo soporte de nuevos idiomas, creando
nuevas implementaciones de la interfaz.
Otros lenguajes ms antiguos, como C++ o
Visual Basic carecen de interfaces. En su lugar
ofrecen otra construccin, las clases abstractas,
tambin presentes en Java y C#.
En C++ una clase es abstracta cuando tiene
uno de sus mtodos "virtual". El modificador
"virtual" es similar al modificador "abstract"
de Java y otros lenguajes. En C++ definira-
mos el contrato de nuestra interfaz con una
clase abstracta (que puede ser pura si todos
sus mtodos son abstractos), y cada una de
las implementaciones de la interfaz seran
clases que heredaran de sta.
Incluso las ltimas versiones de Visual Basic
(5 y 6), antes de su sustitucin por Visual
Basic .NET, permitan la definicin de clases
abstractas. Para tal fin, haba que crear un
mdulo de clase con el asistente visual del
lenguaje, y dar el valor "PublicNoCreatable" a
la propiedad "Instancing" del mdulo. Esto
haca que no se pudiese utilizar ni el opera-
dor "new" ni la funcin "CreateObject" para
obtener instancias de la clase. Un mdulo
poda implementar esta interfaz mediante el
uso de la palabra reservada "implements".
El patrn Delegacin
La delegacin consiste en un medio de exten-
der y reutilizar la funcionalidad de una clase
mediante la creacin de otra clase que se la
proporcione. Todos los lenguajes orientados a
objetos proporcionan mecanismos para
implementar este patrn, pues basta con aa-
dir una nueva referencia a la clase que con-
sume el servicio.
La importancia del patrn Delegacin radica
en que nos proporciona un mecanismo para
decidir cundo debemos hacer que una clase
herede de otra, o cuando aadirle una refe-
rencia para utilizar sus servicios. En nuestro
ejemplo de la clase educada, parece claro que
hay que utilizar delegacin. Muchas veces la
decisin nos la da el sentido comn (la regla
de "es un"), mientras que otras veces habr
que hacer un anlisis del nmero de heren-
cias posibles. En nuestro ejemplo, aadiendo
una referencia a la interfaz "Educado" slo
crearemos una clase que consuma sus servi-
cios, mientras que si optamos por el meca-
nismo de la herencia, tendramos que crear
dos subclases: una de EducadoIngles y otra
de EducadoCastellano. Adems, conforme
fuese creciendo el nmero de implementa-
ciones de Educado, habra que ir aumentan-
do el nmero de herencias. El listado 2 mues-
tra la codificacin en Java de este patrn.
54
DISEO
LISTADO 1
Patrn Interfaz en C#
using System;
class EducadoIngles:Polite{
public void diHola(){
Console.WriteLine("Hello!");
}
public void diAdios(){
Console.WriteLine("Bye!");
}
}
using System;
class EducadoCastellano:Polite{
public void diHola(){
Console.WriteLine("Hola!");
}
public void diAdios(){
Console.WriteLine("Adios!");
}
}
LISTADO 2
Patrn Delegado en Java
//Uso Correcto
public class ConDelegacion{
private Educado;
}
//Uso Incorrecto
public class ConHerencia1 extends EducadoCastellano{
}
public class ConHerencia2 extends EducadoIngles{
}
LISTADO 3
Patrn Singleton en C++
class Singleton {
//Acceso a la instancia a travs de un mtodo esttico
public: static Singleton* Instance();
//Constructor no publico
protected: Singleton();
//unica instancia que puede existir
private: static Singleton* _instance;
};
LISTADO 4
Patrn Singleton en VB.NET
Public Class Singleton
' Unica instncia del Singleton que puede existir (es shared)
Private Shared FInstance As Singleton = Nothing
' Constructor privado
Private Sub New()
End Sub
' Mtodo esttico que da acceso a la propiedad
Public Shared ReadOnly Property Instance()
Get
If (FInstance Is Nothing) Then
FInstance = New Singleton()
End If
Return FInstance
End Get
End Property
End Class
SOLO PROGRAMADORES
Patrones de creacin: Singleton
Una vez introducidos dos de los patrones de
diseo fundamentales, Interfaz y Delegacin,
veremos un patrn del tipo creacional muy
frecuente en la prctica: el patrn de diseo
Singleton.
Este patrn se utiliza cuando queremos garan-
tizar que, de una determinada clase, slo exis-
te una instancia. De esta forma, todos los obje-
tos que hagan uso de esa clase utilizarn la
misma instancia. Cundo suele ser necesario
aplicar un Singleton? Cuando nos encontramos
con clases que deben encargarse de gestionar
un recurso, bien sea externo (las conexiones a
una base de datos, por ejemplo), bien sea inter-
no (informacin de configuracin global a nivel
de sistema, informacin nica para el contexto
de la aplicacin, etc.)
Cmo se implementa un Singleton? En primer
lugar, se debe impedir que los clientes constru-
yan instancias de la clase que se desea hacer
Singleton. Para ello, lo normal es hacer su cons-
tructor privado. Adems, se debe hacer que
dicha clase contenga una referencia esttica a la
nica instancia de esa propia clase que puede
existir. En el mundo de la orientacin a objetos,
se denomina estticas a aquellas propiedades y
mtodos que son comunes de una clase, y por
tanto compartidas por todas sus instancias. Por
ltimo, se debe aadir al Singleton un mtodo
pblico y esttico que devuelva la nica referen-
cia existente de esa clase.
En el listado 3 vemos un ejemplo de cmo
implementar un Singleton en C++. Con este
lenguaje resulta fcil su implementacin, ya
que permite crear mtodos estticos. El nuevo
lenguaje Visual Basic .NET, de la familia de
lenguajes .NET, tambin proporciona herra-
mientas para implementar este patrn. En el
listado 4 vemos cmo implementar un
Singleton en Visual Basic.NET.
Conclusiones
En esta primera entrega de la serie hemos
hecho una introduccin a los patrones de
diseo de software, y hemos visto tres de los
principales patrones: Interfaz, Delegacin y
Singleton, implementados con diferentes len-
guajes de programacin. El prximo mes
seguiremos profundizando en ste prctico
campo de la ingeniera del software.
55
DISEO
Patrones de diseo: un curso prctico (I)
Gestor de conexiones con el patrn Singleton.
En The Server Side podemos encontrar una seccin dedicada a patrones de diseo
(www.theserverside.com).
Bibliografa recomendada
[1] "A Pattern Language: Towns, Buildings, Construction." Christopher Alexander. 1977.
[2] "Using Patterns Languages for Object-Oriented Programs". Ward Cunningham, Kent Beck. 1987
[3] "Design Patterns: Elements of Reusable Object Oriented Software". Gamma, Helm, Vlissides y Jhonson. 1994
[4] "Patterns Of Enterprise Application Architecture", Martin Fowler
[5] "Java Blueprints" http://java.sun.com/blueprints/patterns/catalog.html
[6] ".NET Enterprise Patterns". http://msdn.microsoft.com/practices/type/Patterns/Enterprise/
[7] "Patterns in Java: A Catalog of Reusable Design Patterns Illustrated with UML" Mark Grand.
Diagrama de clases UML del patrn Delegacin