Documente Academic
Documente Profesional
Documente Cultură
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
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.
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
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]):
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