IntroduccinaDesignPatterns

Introduccin
aDesignPatterns

Por
FernandoDodino
NicolsPasserini

Versin2.1
Mayo2007

IntroduccinaDesignPatterns

Indice
QunoesunDesignPattern?
Frameworkvs.Pattern
QuhaydetrsdelosDesignPatterns?
PorqudamosDesignPatterns?
CmoaplicarlosDesignPatterns?
Cmonousarlos(ConsejodeGamma)
CundoaplicarDesignPatterns?

IntroduccinaDesignPatterns

Y l le dijo al Programador: Yo soy el Gamma y el Omega.

Sube a encontrarte conmigo en el monte, y qudate all.
Voy a darte las tablas con la ley
y los patterns que he escrito para guiarlos en la vida.
xodo 24:11-13

QuesunDesignPattern?
UnDesignPattern:
es una regla que expresa la relacin entre un contexto, un problema y una
solucin(ChristopherAlexander,creadordePatternsparalaIngenieraCivil)

"Each pattern describes a problem which occurs

over and over again in our environment, and then
describes the core of thesolution to that problem, in such
a way that you can use this solution a million times over,
without ever doing it the same way twice" (nuevamente
Christopher Alexander, segn el libro Design Patterns del
Gang of Four algo as como loscuatrofantsticos:Erich
Gamma, Richard Helm, Ralph Johnson, y John
Vlissides). A partir de aqu nos referiremos a esta
bibliografacomoellibrodeGamma.

Una solucin (probada) a un problema en un determinado contexto (Erich

Gamma)
A Design Patternnames,abstractsandidentifiesthekey aspectsofacommon
design structure that make it useful for creating a reusable objectoriented
design.(nuevamente,ErichGammadixit)

Partiendodeestasdefiniciones,definimosqudebecontenerunpattern:

Unnombrequedescribeelproblema.Estonospermite:

Tener un vocabulario de diseo comn con otras personas. Un pattern se

transforma en una herramienta de comunicacin con gran poder de
simplificacin1
Por otra parte, logramos un nivel de abstraccin mucho mayor. De la
misma manera que una lista doblemente enlazada define cmo se
estructura el tipo de dato y qu operaciones podemos pedirle, el pattern
trabaja una capa ms arriba: define un conjunto de objetos/clases y cmo
se relacionarn entre s (resumindolo en una palabra). Ya existan
conceptossimilaresenlaprogramacinestructurada:elapareoyelcortede
control(definanlaformadeencararlasolucin).
1

Se puede estudiar el gato El explicado, de Les Luthiers para recordar la importancia de los
nombres:http://www.atame.org/l/les_luthiers/el_explicado.shtml
3

IntroduccinaDesignPatterns

El problema define cundo aplicar el pattern, siempre que el contexto lo haga

relevante.

La solucin contiene un template genrico de loselementosquecomponeneldiseo,

sus responsabilidades, relaciones y colaboraciones. Un pattern no es instanciable per
se,laabstraccinrepresentadaenelproblemadebeaplicarseanuestrodominio.

En las consecuencias se analiza el impacto deaplicar unpatternenlasolucin,tanto

afavorcomoencontra.

QunoesunDesignPattern?
UnDesignPattern:

No es garanta de un sistema bien diseado. Tengo las respuestas, perome

faltasabersihicelapreguntacorrecta.

Es un buen punto de partida para pensar una solucin, no lasolucin. Al ser

una herramienta, no puede reemplazar al diseador, que es quien maneja la
herramienta.

De la misma manera que los estudiantes de psicologa encuentran rasgos de

neurosis obsesiva entre sus parientes, amigos e incluso en s mismos, el
estudiante de patterns suele querer descubrir patrones en su solucin an
cuando no siempre se justifique. Entonces aparecen signos de sobrediseo:
abuso por prever todo tipo deescenarios.ElmismoErich Gammanosbrindar
consejosmsadelantesobrecmonousarlosDP.

Est en la pgina anterior, pero vale la pena recalcar que un pattern no es

instanciable, y no es dependiente de un dominio. Es el bosquejo de una
idea que ha servido en otras ocasiones, para una problemtica similar.
Representaunaunidaddeabstraccinmayorasimpleslneasdecdigo.

Frameworkvs.Pattern
Mientras que los frameworks2 trabajan en un dominio concreto (testing, persistencia,
exportacin a pdf, etc.) los patterns son soluciones generales independientes del
dominioquenecesitanaplicarseenuncontextoparapoderserimplementados.

Paraunaexplicacindelconceptoframeworkvase:
http://uqbarwiki.org/index.php?title=Libreria_y_Framework

IntroduccinaDesignPatterns

QuhaydetrsdelosDesignPatterns?
Desde tiempos inmemoriales la industria del software ha tratado de lidiar con la
complejidad intrnseca del problema de construir sistemas intentando llegar a una
perspectivaingenierildelproblema.
En determinado punto de la historia la mayora de los componentes de la industria
estaban de acuerdo con esa perspectiva, vinculada a un desarrollo en cascada,
haciendo nfasis en que los procesos estn por encima delas personasyviendoal
desarrollodesoftwarecomounacadenademontaje.
Tarde o temprano, las personas vinculadas al desarrollo fueron descubriendo (o
descubrirn algn da) que ese esquema no daba los resultados esperados. Que la
visin de la cadena de montaje no aplica a la produccin de software y
principalmente que los ciclos de vida en cascada no aplican anuestraindustria. La
metforadelaingenieraciviltampocofuesuficiente.
Ante ese panorama, se abrieron dos caminos, el primero sugiere hacer algunas
correcciones al modelo de ingeniera original (diramos que correcciones menos
radicales de lo que a veces se pretende hacernoscreer,peroesaesotradiscusin)
ysepropusieronotrosmodelosmsomenosingenieriles.
El segundo camino, diametralmente opuesto, sugiere que el software slo puede
construirse de manera artesanal y propone no confiar en los procesos, dando una
importanciamuchomayoralaspersonaseneldesarrollo.
Existiendo argumentos para ambas lneas de pensamiento, entendemos que esa
discusin slo esmantenibleafuturo.Esdecir,quelaesperanzadequelaingeniera
nosbrindeunmtodo(una'receta')quenosdigadeunavezyparasiempre cmose
hace para construir software no tiene asidero para el estado actual del arte de
construirsistemasdesoftware.
Desde nuestro punto devista, la gran mayora de los proyectos exitosos hoyen da
depende para elhorrordelosingenierosensoftware enunaltsimoporcentajedela
capacidad de las personas y nodelametodologaqueseutiliceytampocosepuede
decir que esas personas tampoco siganunmtododefinidosinoquesusdecisiones
sebasanprincipalmenteenlaexperienciayenlaintuicin.
Por lo tanto, en la situacin actual el trabajo del ingeniero consiste en formalizar la
forma en que se tomanesas decisiones e ir generando herramientasapartirdeese
proceso de formalizacin. En todos los aspectos de la ingeniera se puede ver ese
mecanismo, en lugar de tener un 'proceso' o 'metodologa' lo que tenemos son
'patterns'y'bestpractices'.
Pero, qu es una best practice? Una best practice es un esfuerzo por formalizar
una actividad que anteriormente se dio en forma natural, describir su utilidad, sus
caractersticas y debilidades, con el objetivo de poder reutilizarla donde sea
conveniente. Cuandodescubrimos algo que nos da resultado, tratamos de repetirlo.
Cuando descubrimos que se puede adems dar resultado en mltiples ocasiones,

IntroduccinaDesignPatterns

encontramoslaoportunidaddeponerleunnombreyformalizarlaidea.
Un design patternesentonceslaintencin porformalizarunaprcticadediseo,una
herramienta para disear. Notenemos hoy unmecanismoquenospermitapasarde
un conjunto de requerimientos a un diagrama de clases o de secuencia ninadaque
se le parezca. Cualquiera que haya tratado de utilizar los mecanismos
pseudoautomticos propuestos por las grandes consultoras del tema, habr
descubiertoquenotienennadadeautomtico.
Tal vez en algn momento la industria madure lo suficiente para encontrar un
proceso totalmente ingenieril que nos permita realizar esa transformacin en 7
simples pasos. Hasta ahoraeso no ha ocurrido y tal como lo predijeraFredBrooks3
en 1986, seguimos sin encontrar 'silver bullets': el diseo es un proceso arduo,
manual, artesanal e iterativo. Ante la ausencia de ese proceso mgico, lo que nos
queda esayudar a nuestras pruebas y errores (iterativo tienemuchode "a prueba y
error")conalgunas'ideaspiolasquevemosquepuedencalzarenmuchoslugares'.
A esas ideas piolas le ponemos nombres para extender nuestro lenguaje. A veces
nos sirven 'out of the box' del libro a nuestro diagrama de clases, en otras
oportunidadesslosirvencomodisparadorasdeotrasideasnuevas.

Frederick P.BrooksJr.,ingeniero desoftware queescribi elensayo No SilverBullet essence

and accidents of software engineering donde pronostic las limitaciones de las tecnologas a
lahoraderesolverlascomplejidadesintrnsecasdeunproblema.Recomendamossulecturaen:
http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/nosilverbullet.pdf
Profundo investigador del proceso dedesarrollode software, esautor de unafraseconocidacomo
La Ley de Brooks: Agregar gente a unproyectoretrasado retrasael proyecto.La justificacin no
podrasermsclara:Nopodemosesperarquenuevemujerespuedantenerunbebenunmes.
6

IntroduccinaDesignPatterns

PorqudamosDesignPatterns?

Porque abre la mente, nos da la capacidad de explorar mejoras a nivel de

diseo (no slo estamos tirando cdigo sino que nos paramos una capa ms
arriba).
Porque al adaptarnos alvocabulariodelacomunidadganamostiempo.Noeslo
mismo
Hacer un diseo donde nos damos cuenta que hay diferentes criterios
para calcular punitorios por no pagar un crdito, tener que comunicar
esa mismaideaalequipodedesarrollodiciendoDebemossubclasificar
loscriterios,peromeparecequeserabuenodespegarlodelclientepara
que no queden acoplados el cliente y el criterio que tenemos para
calcularlepunitoriospornopago,etc.etc.
Decir El cliente tiene un strategy para calcular punitorios. Pudimos
transmitir la misma idea con menos palabras: logramos mayor
expresividad llevando la discusin a un nivel mucho ms alto y
conceptual.
Nos obliga a ir adelante y atrseneldiseoyno pensarexclusivamenteenuna
solucin de compromiso para hoy. Esto no slo produce diseos ms
elegantes,sinoqueastambinaprendoa equilibrarhastacundodejolapuerta
abierta para cambios y hasta cundo cierro una solucin para poder
implementarla.
Es una forma de documentacin. Muchas veces nos ha pasado tener un dej
vu y no recordar en qu ocasin hicimos algo parecido. Ponerle un nombre
tambinayudaadocumentarnuestrotrabajoyacomunicarloalosdems.

IntroduccinaDesignPatterns

CmoaplicarlosDesignPatterns?
En http://hillside.net/patterns/patternscatalog tenemos un catlogo actualizado de
patterns, adems de los 23 originales del libro del Gang of Four. Evitando caer en
recetasmetodolgicas4 ,haydosmanerasdeabordarlospatronesdediseo:

Teniendounproblemaconcretoqueresolver(lamejormotivacin)
Como lectura de inters para situaciones futuras (me sirve para guardar enla
cajadeherramientasdeldiseador).

Enelcasodedisearalgunaaplicacin,nospuedepasarque:

necesitemosresolveralgncasonotrivialynosepamoscmo

sabemos cmo resolverlo pero queremos contrastar nuestra

solucin con otra que ya funcion en otros casos (y aun as nos
podemos seguirquedando connuestra ideaoriginal,soloqueahora
con ms fundamento). Lo ms importante del diseo son las
preguntas, y aquse abrenmuchoscaminosposibles:misolucin
encaja con algn pattern existente? o son ms de uno
relacionados? mi solucin est bien para hoy pero no contempla situaciones que
sevanadaracortoplazo?etc.etc.

Estudiar los Design Patterns es fcil. Lo difcil es saber qu patterns calzan en mi

solucin para darle al sistema robustez y flexibilidad,y para esocomodecamosantes
no existe ninguna herramienta automtica. Slo podemos tener en cuenta algunos
consejos:

Cada Pattern tiene tres secciones que describen el problema que resuelve: Intent,
Motivation y Applicability. Leer estas secciones nos ayudar a comprender si la
naturalezadelproblemaencajaconlasolucinpropuestaporel/lospattern/s.

Lospatternsseagrupanentresgrandescategoras:
1. Creacionales:abstraenelprocesodeinstanciacin,
2. Estructurales: se ocupan de generar estructuras entre clases y objetos, se
estudianconlosdiagramasdeclases/objetos+cdigoy
3. de comportamiento: se encargan de la asignacin de responsabilidades entre
objetos y cmo se comunican entre s, se estudian con diagramas de
secuencia/colaboracin+cdigo.
Adems, muchos patterns estn relacionados entre s, lo que afortunadamente est
documentadoynosayudaenlaeleccin.
4

El lector interesado en propuestas metodolgicas puede abordar Instrucciones para dar cuerda
a unreloj eInstruccionesparasubirunaescalera del libroHistoria de Cronopiosy deFamas, de
JulioCortzar
8

IntroduccinaDesignPatterns

No todo puede ser variable en el diseo. De ser as,generaramos una pieza de

software tan abstracta quenoserviraparaningnnegocio.Qunosinteresarapoder
cambiar el da de maana? Gamma recomienda concentrarse en encapsularla parte
msvariabledenuestraaplicacin.

Ejemplo:Enunafunerariavieneunclienteysolicitaunaparcela

Va a ser difcil probar que el State Pattern calceenestaaplicacin,teniendoencuenta

que es difcil que vare el estado de un cliente (vivo, muerto, mmm podra agregar
msestadosafuturo?).

Distintopuedesersiquierotrabajarelestadodeunaparcela:

siemprequeeldominiolojustifique.

Una vez elegido el pattern, lo estudiamos y generamos el diagrama declasesdndole

nombres representativos a las clases en base al contexto. Para elegirlosnombres,a
veces conviene utilizar como sufijo el nombre del rol que cumple la clase dentro del
9

IntroduccinaDesignPatterns

pattern: DepositoObserver, es elobjeto encargado de ser notificado ante cualquier

cambioquesufraeldepsito.

De todas maneras no siempre es recomendable ensuciar la semntica deunaclase

cuando el nombre de sta es lo suficientemente representativo: DepositoSubject
no parece tan buena eleccin como Depsito (si al fin de cuentas es el objeto de
negocio representado). Adems, una clase puede estar participando en ms de un
patternalavez.

Cmonousarlos(ConsejodeGamma)
Cada vez que decidimos flexibilizaruna parte de nuestro sistema,estamosagregando
complejidad al diseo y esto redunda en unmayorcostodeimplementacin.Aparecen
fuerzascontrapuestas:

Los Design Patterns no deben ser usados indiscriminadamente. Si bien logramos

mayor flexibilidad, tambin agregamos niveles de indireccin que pueden complicar el
diseo y/o bajar la performance. Un patrn de diseo slo debera usarse cuando la
flexibilidadpaguesucosto.

En las pginas 24 y 25 del libro de Gamma se enumeran ocho causas comunes de

rediseo, junto con los patterns que trabajan sobre esos problemas recomendamos
ampliamentesulectura.

CundoaplicarDesignPatterns?
Enquciclodevidadeundesarrollodeberaaplicarlos?
En esa sutil diferencia entre el qu y el cmo, el Anlisis queda fuera de juego
(todava estoy conociendo el dominio y definiendo la funcionalidad del sistema
conmicliente).
A favor de la etapa de Diseo es que son Design Patterns. En la fase de
Diseo todava me falta experiencia en el dominio, pero puedo buscar lo que
puedecambiarenelsistemaconayudadealgnusuarioexperto.
En la programacin? Mmm, si al leer el cdigo que vamos escribiendo
notamos queaparece un pattern no diseadoentoncestenemosqueactualizar
eldiseo.
VeamosqusucedeenlaetapadeMantenimiento5

Extractado de Erich Gamma et.al, Design Patterns Elements of Reusable ObjectOriented

Software,AddisonWesley,pg.354
10

IntroduccinaDesignPatterns

Como concepto novedoso, Gamma plantea que para que un sistema pueda
evolucionar,necesitadosfases:

1. Aceptar los requerimientos de los usuarios. Esto lleva un perodo deexpansin

delsoftware.

2. En algn momento, el sistema necesita detener todos los requerimientos y

acomodarse, volverse ms flexible para poder convertirse en una pieza de
software lo suficientemente maleable para volver a aceptar nuevos
requerimientos.Esteprocesoseconocecomorefactorizacin.

Cada espiral de refactorizacin de un sistema es un buen momento para hacer mi

diseo ms general como ya tengo cierto knowhow del dominio, aqu es donde ms
fcilpuedodeterminarsiaplicar(odescartar)patterns.

11