El aprendizaje ms importante proviene de la experiencia directa.

Nonaka & Takehuchi

El lenguaje de patrones brinda a todo el que lo utilice el poder de crear una infinita
variedad de construcciones nuevas y nicas, de la misma forma que su lenguaje
comn le brinda el poder de crear una infinita variedad de oraciones."
Christopher Alexander
Introduccin
En toda tarea humana, podemos encontrar una serie de patrones que se repiten
y que poseen caractersticas comunes que nos permiten clasificarlos.
Era de esperar, por tanto, que alguien se animara tarde o temprano a estudiar los
distintos patrones que pueden encontrarse en la inmensa mayora del software, de
forma que los problemas solucionados por estos quedasen perfectamente
clasificados junto con su solucin, para que as no fuese necesario reinventar la
rueda cada vez que un programador se enfrentase a un obstculo similar al
descrito en uno de estos patrones. Nacieron as los patrones de diseo de
sistemas software.
Si eres programador seguro que has odo hablar de los patrones de diseo. Es
posible incluso, que ya los ests utilizando en tus aplicaciones sin conocerlos
como tal.
Los patrones de diseo son una herramienta muy til. Cualquier programador
debera conocer, por lo menos, los patrones ms utilizados. Y es que tenerlos
en nuestra caja de herramientas nos puede ahorrar muchos dolores de cabeza.
Estos patrones se aplican a la programacin orientada a objetos.

Primera aparicin
Aunque fue en 1987 cuando apareci el primer artculo que hablaba de patrones
del lenguaje en programas orientados a objetos, no fue probablemente hasta 1990
cuando comenzaron a ser conocidos extensamente por la comunidad de
desarrolladores. Ese ao se publicaba el libro Design Patterns, escrito por el
grupo Gang of Four, el cual estaba compuesto por Erich Gamma, Richard Helm,
Ralph Johnson y John Vlisides. En este famossimo libro, a menudo referenciado
como GoF, los autores recogan 23 patrones comunes en el diseo de software,
explicando al detalle en qu consistan y describiendo las soluciones adoptadas
tpicamente para cada problema.
Requisitos de un patrn de diseo
Un patrn de diseo debe cumplir al menos dos requisitos para considerarse como
tal: Debe ser efectivo, de modo que se haya podido comprobar su xito

resolviendo problemas anteriores; y debe ser reutilizable, es decir, podemos

aplicarlo a problemas que se hallan en circunstancias similares a las descritas por
el patrn.
Los
patrones
descritos
en
GoF
se
dividen
en
tres
tipos: Creacionales, estructurales y de comportamiento. Su conocimiento y
estudio permiten reconocer los problemas ms tpicos de forma rpida y efectiva,
resolvindolos en tiempos rcord sin sacrificar demasiado la extensibilidad. Y
sobre todo, permite mantener un lenguaje comn entre programadores a la hora
de referenciar un problema: Imagina cun sencillo sera poder comentar un
problema de diseo con un compaero, y poder decirle algo tan sencillo como:
Esto es un patrn adapter; siendo este breve comentario suficiente como para
que tu interlocutor te entendiese perfectamente y sepa cmo hay que resolver el
problema al que os enfrentis.
Qu son los patrones de diseo?
Los patrones son una disciplina de resolucin de problemas reciente en la
ingeniera del software que ha emergido en mayor medida de la comunidad de
orientacin a objetos, aunque pueden ser aplicados en cualquier mbito de la
informtica y las ciencias en general.
En el libro The Timeless Way of Building [Alexander79] (obra de referencia
donde se plantea por primera vez la teora de los patrones aplicada a la
Arquitectura Civil y Urbanismo), el Arquitecto Christopher Alexander define al
patrn en la siguiente manera:
Cada patrn es una regla de 3 partes, que expresa una relacin entre un
contexto, un problema y una solucin. Como un elemento en el mundo, cada
patrn es una relacin entre un contexto, un sistema de fuerzas que ocurren
repetidamente en ese contexto y una configuracin espacial que permite que esas
fuerzas se resuelvan entre s.
Como elemento de un lenguaje, un patrn es una instruccin que muestra como
puede ser usada esta configuracin espacial una y otra vez para resolver el
sistema de fuerzas, siempre que el contexto lo haga relevante.
Podemos agregar otro prrafo de Alexander, citado en la obra de referencia
Design Patterns [GoF95] en la seccin Qu es un patrn de diseo?:
Cada patrn describe un problema que ocurre una y otra vez en nuestro entorno,
para describir despus el ncleo de la solucin a ese problema, de tal manera que
esa solucin pueda ser usada ms de un milln de veces sin hacerlo ni siquiera
dos veces de la misma forma.
Para Alexander, estos patrones son ubicuos y permiten alcanzar la calidad sin
nombre (Quality Without a Name QWAN). Para aclarar estas definiciones,

podemos utilizar un ejemplo concreto aplicado a la construccin, tomado tambin

de la obra de Alexander:
Si nos fijamos en las construcciones de una determinada zona rural,
observaremos que todas ellas poseen apariencias parejas (tejados de pizarra con
gran pendiente, etc.), pese a que los requisitos personales por fuerza han debido
ser distintos. De alguna manera la esencia del diseo se ha copiado de una
construccin a otra, y a esta esencia se pliegan de forma natural los diversos
requisitos. Dirase aqu que existe un patrn que soluciona de forma simple y
efectiva los problemas de construccin en tal zona. [AIX77]
Los patrones de diseo son soluciones para problemas tpicos y
recurrentes que nos podemos encontrar a la hora de desarrollar una aplicacin.
Aunque nuestra aplicacin sea nica, tendr partes comunes con otras
aplicaciones: acceso a datos, creacin de objetos, operaciones entre sistemas etc.
En lugar de reinventar la rueda, podemos solucionar problemas utilizando algn
patrn, ya que son soluciones probadas y documentadas por multitud de
programadores.
A modo de complemento, considero muy importante e interesante citar 2 principios
postulados por Martin Fowler en Analysis Patterns [Fowler97] y que debemos
tener en mente en todo momento al utilizar patrones:

Los patrones son un punto de partida, no un destino.

Los modelos no estn bien o mal, sino que son ms o menos tiles.

Como reflexin final de esta seccin, podemos aadir que un patrn de diseo no
es una solucin en s misma, sino la documentacin de la forma en que
construyeron soluciones a problemas similares en el pasado, lo cual permite una
mejor gestin de la experiencia y transferencia de conocimientos.
Por qu usar patrones de diseo?
Como ya vimos en el artculo sobre principios de diseo, si queremos desarrollar
aplicaciones robustas y fciles de mantener, debemos cumplir ciertas "reglas". Lo
pongo entre comillas porque aunque estas reglas de diseo son recomendables
(muy recomendables), no son obligatorias. Siempre podemos decidir no aplicarlas.
Aunque si no lo hacemos, hay que ser conscientes de la razn de no aplicarlas y
de sus consecuencias.
Los patrones de diseo nos ayudan a cumplir muchos de estos principios o
reglas de diseo. Programacin SOLID, control de cohesin y acoplamiento o
reutilizacin de cdigo son algunos de los beneficios que podemos conseguir al
utilizar patrones.

Cuntos patrones de diseo existen? Tengo qu conocerlos todos?

Patrones de diseo hay muchos. Muchsimos. Y siguen apareciendo patrones
nuevos cada poco tiempo. El desarrollo de aplicaciones es una disciplina en
constante cambio. Por tanto los problemas a los que nos enfrentamos los
desarrolladores tambin cambian. As que las herramientas utilizadas, tambin se
van actualizando y mejorando.
Es imposible conocer todos los patrones de diseo. Lo ms til es tener
un catlogo de patrones que podamos consultar. A la hora de desarrollar una
aplicacin, podremos consultar nuestro catlogo buscando patrones que nos
ayuden a solucionar problemas de diseo concretos.
Qu tipos de patrones existen?
Existen diversas maneras de agrupar los patrones de diseo. Quiz la ms
extendida es agruparlos segn su propsito. En este caso tendramos las
siguientes categoras:

Patrones creacionales: utilizados para instanciar objetos, y as separar la

implementacin del cliente de la de los objetos que se utilizan. Con ellos
intentamos separar la lgica de creacin de objetos y encapsularla.

Patrones de comportamiento: se utilizan a la hora de definir como las

clases y objetos interaccionan entre ellos.

Patrones estructurales: utilizados para crear clases u objetos que

incluidos dentro de estructuras ms complejas.

Puedo desarrollar nuevos patrones?

Como ya he dicho antes, cada poco tiempo aparecen nuevos patrones o
revisiones de los ya existentes. Es algo lgico si tenemos en cuenta que nuestra
forma de programar est evolucionando continuamente. Nuevos frameworks,
nuevas plataformas, nuevos tipos de acceso a datos etc.
Por tanto, es factible que cualquiera pueda "descubrir" un nuevo patrn.
Lgicamente el supuesto patrn deber ser puesto a prueba por la comunidad
de desarrolladores. Para ello deber demostrar que es nuevo, que es correcto y
que es til para solucionar problemas comunes de desarrollo. Un patrn no ser
tal si solo sirve para solucionar un problema especfico de nuestra aplicacin.
Conclusiones
La conclusin es sencilla, si no usas patrones, deberas hacerlo. Los patrones
ayudan a estandarizar el cdigo, haciendo que el diseo sea ms comprensible
para otros programadores. Son muy buenas herramientas, y como
programadores, siempre deberamos usar las mejores herramientas a nuestro
alcance.

Eso s, siempre con cabeza y sentido comn. De nada vale aplicar patrones sin
una buena razn. Y t utilizas patrones? Cules son los que ms utilizas?
Patrones de software
Los patrones de software facilitan la reutilizacin del diseo y de la arquitectura,
capturando las estructuras estticas y dinmicas de colaboracin de soluciones
exitosas a problemas que surgen al construir aplicaciones.
Cada patrn es una regla de 3 partes, que expresa una relacin entre un contexto,
un sistema de fuerzas que ocurren repetidamente en ese contexto y una
configuracin de software que permite que se resuelvan esa fuerzas.
Otra definicin complementaria, ms enfocada en el mbito tcnico, es la que se
da en el libro de Microsoft Enterprise Development Reference Architecture
[Microsoft04]:
Una descripcin de un problema recurrente que ocurre en un contexto
determinado y, basada en un conjunto de fuerzas, recomienda una solucin. La
solucin es usualmente un mecanismo simple: una colaboracin entre dos o ms
clases, objetos, servicios, procesos, tardeas, componentes o nodos que trabajan
juntos para resolver el problema identificado por el patrn.
Los patrones le ayudan a construir sobre la experiencia colectiva de ingenieros de
software experimentados. Estos capturan la experiencia existente y que ha
demostrado ser exitosa en el desarrollo de software, y ayudan a promover las
buenas prcticas de diseo. Cada patrn aborda un problema especfico y
recurrente en el diseo o implementacin de un sistema de software.
Caractersticas de un buen patrn
Documentar buenos patrones puede ser una tarea muy difcil. Citando a James
Coplien en [Hillside03], un buen patrn:
1. Resuelve un problema: Los patrones capturan soluciones, no principios o
estrategias abstractas.
2. Es un concepto probado: Capturan soluciones, no teoras o
especulaciones. En el caso del Design Patterns, el criterio para decidir si
algo era un patrn o no, era que ste deba tener al menos 3
implementaciones reales.
3. La solucin no es obvia: Muchas tcnicas de resolucin de problemas
(como los paradigmas o mtodos de diseo de software) intentan derivar
soluciones desde principios bsicos. Los mejores patrones generan una
solucin a un problema indirectamente (un enfoque necesario para los
problemas de diseo ms difciles).
4. Describe una relacin: Los patrones no describen mdulos sino
estructuras y mecanismos. Tiene un componente humano significante:
El software sirve a las personas. Los mejores patrones aplican a la esttica
y a las utilidades (de hecho, no es casual que varios de los primeros

lenguajes de patrones tengan que ver con temas estticos y utilidades

como Hot Draw ET++).
Lenguajes y sistemas de patrones
Un lenguaje de patrones contiene un amplio conjunto de patrones, cuyas
combinaciones conforman su gramtica. Segn Alexander, un lenguaje de
patrones provee la misma expresividad que un lenguaje natural, pero aplicada a la
construccin.
Un sistema de patrones mantiene unidos a sus patrones. Describe la forma en que
se conectan y cmo se complementan entre ellos. Un sistema de patrones facilita
el uso eficaz de los patrones en el desarrollo de software. Por lo tanto, podemos
decir que un sistema de patrones es una coleccin de patrones, junto con las
guas para su implementacin, combinacin y uso prctico en el desarrollo de
software. Un sistema de patrones es similar a un lenguaje de patrones, aunque
este ltimo tiene fuertemente asociado el concepto de generatividad e implica que
cubre todos los aspectos de importancia en un dominio particular. La combinacin
de sistemas de patrones puede conformar un lenguaje de patrones, donde la
gramtica se establece a partir de las combinaciones de estos patrones. Un
lenguaje de patrones define una coleccin de patrones y las reglas para
combinarlos en un estilo arquitectural. Los lenguajes de patrones
describen frameworks de software o familias de sistemas relacionados.
Niveles de patrones
En Pattern Oriented Software Architecture, Volumen 1 [Buschmann96], se
define una taxonoma como la que se muestra en la Figura 1. Los patrones en
cada grupo varan respecto a su nivel de detalle y abstraccin.

Figura 1: Patrones segn el nivel de detalle, adaptado de POSA. Volver al texto.

Es importante destacar que esta divisin no es absoluta ni totalmente
comprehensiva, dado que no incluye a otros patrones de amplia aceptacin y
utilizacin como los de anlisis, integracin de aplicaciones, pruebas, etc.

Pattern Happy
El trmino Patterns Happy aparece en el libro Refactoring to Patterns
[Kerievsky04] y es un calificativo aplicable a los programadores que se refiere al
uso indiscriminado de patrones, aun cuando su utilizacin no agrega ningn valor
a la solucin que se esta desarrollando. Un programador Pattern Happy aprende
un patrn e inmediatamente encuentra un lugar para abusar de l. Para clarificar
mejor este concepto, incluyo un breve prrafo de Refactoring to Patterns donde
se define este calificativo de la siguiente forma:
Has aprendido alguna vez algn patrn de software y quisiste usarlo en ese
mismo momento, porque te gust? Mucho? Entonces eres un amante de los
patrones. Los patrones no son siempre la solucin adecuada o mejor para un
problema. Si bien aaden flexibilidad, tambin aaden complejidad. Es por esto
que se debe ser cuidadoso al momento de seleccionar patrones. Siempre hay que
recordar que los patrones son un punto de partida y que no son dogmas
incuestionables. El uso indiscriminado de patrones, an en situaciones donde no
aportan ningn beneficio, puede ser un antipatrn o un claro indicador de ser un
Pattern Happy (esto es alguien que abusa de los patrones sin razn).
Los patrones y la Gestin del Conocimiento
Los patrones permiten establecer un vocabulario comn de diseo, cambiando el
nivel de abstraccin a colaboraciones entre clases y permitiendo comunicar
experiencia sobre dichos problemas y soluciones.
Son tambin un gran mecanismo de comunicacin para transmitir la experiencia
de los ingenieros y diseadores experimentados a los ms noveles, convirtindose
en unas de las vas para la gestin del conocimiento.
Lo que se pretende con un catlogo de patrones no es favorecer al diseador
experto (que quizs no necesite en absoluto los patrones), sino ms bien ayudar al
diseador inexperto a adquirir con cierta rapidez las habilidades de aqul, como
tambin comunicar al posible cliente, si es el caso, las decisiones de diseo en
forma clara y autosuficiente [Cueva04].
Un patrn de diseo describe una estructura recurrente de componentes que se
comunican para resolver un problema general de diseo en un contexto particular.
Nomina, abstrae e identifica los aspectos clave de una estructura de diseo
comn, lo que los hace tiles para crear un diseo orientado a objetos reutilizable.
Identifica las clases e instancias participantes, sus roles y colaboraciones y la
distribucin de responsabilidades. Tiene, en general, 4 elementos esenciales (los
cuales se explican en gran detalle en el libro Design Patterns [GoF95]):

Nombre: Permite describir, en una o dos palabras, un problema de diseo

junto con sus soluciones y consecuencias. Al dar nombres a los patrones
estamos incrementando nuestro vocabulario de diseo, lo cual nos permite
disear y comunicarnos con un mayor nivel de abstraccin (en lugar de
hablar de clases individuales nos referimos a colaboraciones entre clases).
Problema: Describe cundo aplicar el patrn. Explica el problema y su
contexto. A veces incluye condiciones que deben darse para que tenga
sentido la aplicacin del patrn.
Solucin: Describe los elementos que constituyen el diseo, sus
relaciones, responsabilidades y colaboraciones. La solucin no describe un
diseo o implementacin en concreto, sino que es ms bien una plantilla
que puede aplicarse en muchas situaciones diferentes.
Consecuencias: son los resultados, as como ventajas e inconvenientes de
aplicar el patrn.

Los patrones de diseo no son dogmas que deben ser aceptados. Qu es y qu

no es un patrn de diseo, es una cuestin que depende del punto de vista de
cada uno y del nivel de abstraccin en que se trabaje.
Una de las heursticas para establecer un patrn, es que existan al menos 3
implementaciones en aplicaciones reales. Por tanto, los patrones de diseo no son
abstracciones tericas, sino que estn fundados sobre una fuerte base prctica y
pragmtica, producto de la experiencia.
Principios de Diseo
En el libro del GoF se propone unos principios fundamentales de diseo
subyacentes a los patrones de diseo que permiten crear aplicaciones ms
flexibles y robustas:

Programar para interfaces y no para una implementacin.

Favorecer la composicin de objetos frente a la herencia de clases.

Otros principios de gran importancia que se derivan de los principios anteriores

son los que se detallan a continuacin:

Determinar qu es comn y qu es variable (commonality analisys).

o Comn = Estable
Permitir el reemplazo de lo variable mediante una interfaz comn.

En este aspecto podemos trazar un paralelismo con los sistemas emergentes,

dado que estos principios individuales, muy sencillos a nivel local, producen
sistemas robustos y flexibles en el nivel macro.
Clasificacin de patrones de diseo:

Como ya dijimos, en el libro del GoF se presentan 23 patrones de diseo, divididos

en 3 categoras, a saber:

De Creacin: Abstraen el proceso de creacin de instancias de objetos.

Ayudan a hacer a un sistema independiente de cmo se crean, se
componen y se representan sus objetos.
Estructurales: Tratan con la composicin de clases u objetos. Se ocupan
de cmo las clases y objetos son utilizados para componer estructuras de
mayor tamao.
De Comportamiento: Caracterizan el modo en que las clases y objetos
interactan y se reparten la responsabilidad. Ataen a los algoritmos y a la
asignacin de responsabilidades entre objetos.

De Creacin
mbit
o

Estructurale
s

De Comportamiento
Interpreter
Template Method

Clase

Factory Method

Adapter
clase)

(de

Objeto

Abstract
Factory
Builder
Prototype
Singleton

Adapter (de
objetos)
Bridge
Composite
Decorator
Faade
Flyweight
Proxy

Chain
Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor

of

.
Relajacin de patrones
Muchas veces los patrones son seguidos estrictamente, olvidando que son ms
bien un punto de partida en lugar de una meta. Es interesante observar cmo
incluso en el libro del GoF se relajan ciertas condiciones al momento de
implementar un patrn. Para ver un ejemplo explcito de esto, se recomienda
revisar la implementacin del patrn Abstract Factory en C++ en este libro (hay
tambin otra en Smalltalk).
Sistemas flexibles y robustos con patrones de diseo
En el captulo 2 del libro del GoF, se presenta como caso de estudio la
construccin de un editor de documentos, el Lexi. Luego de una primera lectura,
se puede determinar que sus requisitos no funcionales incluyen la flexibilidad y la
robustez (por ejemplo, el editor puede presentarse en mltiples sistemas de

ventanas y cuando se crean objetos relacionados, siempre son de la misma

familia).
Mediante el uso de patrones de diseo (en este caso concreto, se utilizan 8 de los
23 patrones presentados en el libro) se logra una solucin que cumple con los
requisitos no funcionales (y los funcionales) propuestos. Para mayor detalle sobre
Lexi, ver el captulo 2 de Design Patterns [GoF95].
Los patrones de diseo no son perfectos
Muchas veces se trata a los patrones de diseo como verdades universales. Esto
no puede ser ms incorrecto. De hecho, los miembros del mentado GoF destacan
que los patrones no son un destino sino un punto de partida. En el libro Patterns
Hatching [Vlissides98] John Vlissides, uno de los miembros del GoF, analiza los
patrones de diseo tradicionales desde un punto de vista diferente, intentando
quitar el aura de misticismo que los rodea, detallando incluso el proceso de
descubrimiento de patrones utilizado por el GoF. En esa obra el autor vuelca el
contenido textual de los correos donde se discute si Multicast deba ser un patrn
individual o un caso particular del Observer. Finalmente, Multicast no se public
como patrn en el libro del GoF. En esa misma obra trata temas crticos y muchas
veces ignorados, tales como el ciclo de vida de un Singleton (Cundo y cmo
muere?), los problemas del Observer y cmo reemplazarlo en algunos casos por
un Visitor y prdidas de memoria en el Visitor, entre otros.