Está en la página 1de 10

PATRONES Eva Lleonart Martn Asuncin Garca-Menacho Rovira Facultad de Informtica - Universidad Politcnica de Valencia 1.

Intro uccin Los casos de usos se han llegado a convertirse en la base de muchas metodologas de desarrollo orientadas a objetos. stos generalmente !ro!orcionan el fundamento " el !unto de !artida !ara el resto de los !rocesos de anlisis " desarrollo. Un caso de uso es una secuencia de transacciones en un sistema cu"a tarea es !roducir un valor medible de un actor individual del sistema. Uno de los as!ectos ms im!ortantes de los casos de uso es!ecfica la funcionalidad com!leta de un sistema. Por otra !arte el uso de !atrones !ara el desarrollo de soft#are establece la diferencia entre un buen " un mal dise$o orientado a objetos. Un !atr%n es un fragmento nombrado de informaci%n instructiva& 'ue ca!tura la estructura esencial " la visi%n interna de una familia de soluciones con !robado (ito sobre un !roblema recurrente 'ue surge dentro de un cierto conte(to " fuer)as de sistema. n otras !alabras& rehusar soluciones 'ue funcionaron bien una ve). !. "#u$ es un %atrn& n !rogramaci%n orientada a objetos se entiende !or %atrn una solucin probada que se puede aplicar con xito a un determinado tipo de problemas que aparecen repetidamente en el desarrollo de sistemas software . Los !atrones no son una librera. Van ms bien en la lnea de un es'ueleto bsico 'ue cada desarrollador luego ada!ta a sus necesidades " a las !eculiares caractersticas de su a!licaci%n. *e describen fundamentalmente en forma te(tual& acom!a$ada de diagramas " de seudo-c%digo. +efiniciones, -Un !atr%n es un !eda)o de informaci%n con nombre& instructivo " significante& 'ue ca!tura la esencia de una familia e(itosa " com!leta de soluciones a un !roblema recurrente en un conte(to dado. /rad 0!!leton -1ada !atr%n es una regla de tres !artes& la cual e(!resa una relaci%n entre un conte(to dado& un conjunto de fuer)as 'ue ocurren re!etitivamente en ese conte(to " cierta configuraci%n de soft#are 'ue !ermite a esas fuer)as resolverse !or si mismas. 2ichard 3abriel 1
Laboratorio de *istemas de Informaci%n Facultad de Informtica Universidad Politcnica de Valencia

-1ada !atr%n es una regla de tres !artes& la cual e(!resa una relaci%n entre un cierto conte(to& un !roblema " una soluci%n. l !atr%n es& resumiendo& al mismo tiem!o una cosa 'ue tiene su lugar en el mundo& " la regla 'ue nos dice c%mo crear esa cosa " cundo debemos crearla. s al mismo tiem!o una cosa " un !roceso4 al mismo tiem!o una descri!ci%n de una cosa 'ue tiene vida " una descri!ci%n del !roceso 'ue la gener%. 1hristo!her 0le(ander& 5he 5imeless 6a" of /uilding& 7.898 Un buen !atr%n debe, :*olucionar un !roblema, Un !atr%n ca!tura soluciones& no solo !rinci!ios abstractos o estrategias : s un conce!to !robado :La soluci%n no es obvia :+escribe una relaci%n, ;o solo describen m%dulos& describen estructuras " mecanismos :5iene un com!onente humano significante, es esttico " de utilidad 'a(es )o%lien - stos !atrones en nuestras mentes son& ms o menos& imgenes mentales de los !atrones en el mundo, son re!resentaciones abstractas de las reglas morfol%gicas 'ue definen los !atrones en el mundo. *in embargo& son realmente diferentes. Los !atrones en el mundo solo e(isten. Pero esos mismos !atrones en nuestras mentes son dinmicos. 5ienen fuer)a. *on generativos. ;os dicen 'u hacer& c%mo se !ueden generar "& en ciertas circunstancias& 'ue los debemos crear. 1ada !atr%n es una regla 'ue describe 'ue debemos hacer !ara generar la entidad 'ue los define. 1hristo!her 0le(ander & 5he 5imeless 6a" of /uilding& 7.898 *. +esarrollo histrico l trmino !atr%n se utili)a inicialmente en el cam!o de la ar'uitectura& !or 1hristo!her 0le(ander& a finales de los 9<s. ste conocimiento es tras!ortado al mbito del desarrollo de soft#are orientado !or objetos " se a!lica al dise$o. +e all es e(tra!olado al desarrollo en general " a las dems eta!as. 0lgunos libros 'ue marcan el desarrollo del rea son, 0le(ander& 1hristo!her. 0 Pattern Language, 5o#ns& /uildings& 1onstruction. 7899 0le(ander& 1hristo!her. 5he 5imeless 6a" of /uilding. 7898 3amma et al. +esign Patterns, lementos of 2eusable =bject-=riented *oft#are. 788> /ushmann et al. Pattern-=riented *oft#are 0rchitecture, 0 *"stem of Patterns. 788? 2
Laboratorio de *istemas de Informaci%n Facultad de Informtica Universidad Politcnica de Valencia

1o!lien " *chmidth. Pattern Languages of Program +esign. 788@

0lgunos eventos im!ortantes en la historia del tema de !atrones en Ingeniera de soft#are son, 78A9. 6ard 1unningham " Bent /ecC escriben sus e(!eriencias de ense$ar *malltalC !or medio de las ideas de 0le(ander en Using Pattern Languages for Object-Oriented Programs . 788<. l GoF em!ie)an la reco!ilaci%n de !atrones de dise$o 7887. Dim 1o!lien !ublica su reco!ilaci%n de idioms de 1EE en d!anced "## Programming $t%les and &dioms . 788>. l GoF !ublica el libro 'esign Patterns( )lementos of *eusable ObjectOriented $oftware.

,. Ti%os e %atrones (isten varios ti!os de !atrones& de!endiendo del nivel de abstracci%n& del conte(to !articular en el cual a!lican o de la eta!a en !roceso de desarrollo. 0lgunos de estos ti!os son, +e ar'uitectura +e dise$o Idioms +e anlisis Para ambientes distribuidos +e negocios +e !rocesos " organi)acionales

,.1. Patrones e ar-uitectura *on es'uemas fundamentales de organi)aci%n de un sistema soft#are. s!ecifican una serie de subsistemas " sus res!onsabilidades res!ectivas e inclu"en las reglas " criterios !ara organi)ar las relaciones e(istentes entre ellos. *e recogen a'u ocho !atrones estructurales& agru!ados en cuatro categoras,

3
Laboratorio de *istemas de Informaci%n Facultad de Informtica Universidad Politcnica de Valencia

;iveles +el caos a la organi)aci%n 5uberas " filtros Pi)arra *istemas distribuidos *istemas interactivos P01, Presentaci%n& 0bstracci%n& 1ontrol FicroCernel *istemas ada!tables 2efle(i%n Intermediario o broCer FV1, Fodelo-Vista-1ontrolador

,.!. Patrones e ise.o *on !atrones de un nivel de abstracci%n menor 'ue los !atrones de ar'uitectura. stn !or lo tanto ms !r%(imos a lo 'ue sera el c%digo fuente final. *u uso no se refleja en la estructura global del sistema. )aractersticas e los %atrones e ise.o Son soluciones concretas. Un catlogo de !atrones es un conjunto de recetas de dise$o. 0un'ue e(isten clasificaciones de !atrones& cada uno es inde!endiente del resto. Son soluciones t$cnicas. +ada una determinada situaci%n& los !atrones indican c%mo resolverla mediante ==. Ga" !atrones es!ecficos !ara un determinado lenguaje " otros de carcter ms general. Se a%lican en situaciones (u/ co(unes. Los !atrones de dise$o !roceden de la e(!eriencia& " han demostrado su utilidad resolviendo !roblemas 'ue a!arecen frecuentemente en el +==. Son soluciones si(%les. Indican c%mo resolver un !roblema !articular utili)ando un !e'ue$o nHmero de clases relacionadas de forma 4
Laboratorio de *istemas de Informaci%n Facultad de Informtica Universidad Politcnica de Valencia

determinada. ;o indican c%mo dise$ar un determinado sistema sino s%lo as!ectos !untuales del mismo. 0acilitan la reutili1acin e las clases / el %ro%io ise.o. Los !atrones favorecen la reutili)aci%n de clases "a e(istentes " la !rogramaci%n de clases reutili)ables. La !ro!ia estructura del !atr%n es reutili)ada cada ve) 'ue se a!lica. El uso e un eter(ina o %atrn no se re2le3a clara(ente en el c i4o. 0 !artir de la im!lementaci%n es difcil determinar 'ue !atr%n de dise$o se ha usado. Re2erencias a sel2. Fuchos !atrones utili)an la delegaci%n de o!eraciones " esto !rovoca el !roblema del self. Es i2cil reutili1ar la i(%le(entacin e un %atrn. Las clases del !atr%n son roles genricos& !ero en la im!lementaci%n a!arecen clases concretas. Los %atrones su%onen una so5recar4a e tra5a3o a la hora e

i(%le(entar. *e usan ms clases& es necesario delegar mensajes& etc. *e !ueden organi)ar los !atrones segHn familias de !atrones relacionados . La clasificaci%n facilita la bHs'ueda del !atr%n ms adecuado as como su com!rensi%n . 3amma clasifica los !atrones segHn dos criterios fundamentales, su !ro!%sito " su alcance I3amma 8@J. l propsito refleja lo 'ue reali)a el !atr%n . Los !atrones !ueden tener !ro!%sito de creaci%n& estructural o de conducta. Los !atrones con !ro!%sito de creaci%n conllevan el !roceso de creaci%n de objetos. Los !atrones estructurales tratan de la com!osici%n de clases u objetos. Los !atrones de conducta describen las formas en 'ue las clases u objetos interactHan o distribu"en res!onsabilidades. l alcance indica si el !atr%n a!lica !rinci!almente a clases u objetos. Los !atrones de clases tratan de relaciones entre clases " sus subclases. stas relaciones se establecen a travs de la relaci%n de herencia& !or consiguiente son estticas " definidas en tiem!o de com!ilaci%n. Los !atrones de objetos tratan de relaciones entre objetos 'ue !ueden ser cambiadas en tiem!o de ejecuci%n " son ms dinmicas. 1asi todos los !atrones utili)an la herencia de 5
Laboratorio de *istemas de Informaci%n Facultad de Informtica Universidad Politcnica de Valencia

alguna forma. Pero son los !atrones de clases los 'ue se focali)an en las relaciones de clase. Los !atrones con !ro!%sito de creaci%n " alcance de clase difieren !arte de la creaci%n de objetos a subclases mientras 'ue los !atrones con !ro!%sito de creaci%n " alcance de objeto difieren sta a otros objetos. Los !atrones estructurales " alcance de clase utili)an la herencia !ara com!oner clases& mientras 'ue los !atrones estructurales " alcance de objeto describen formas de ensamblado de objetos. Los !atrones de conducta con alcance de clase utili)an herencia !ara describir algoritmos " flujos de control mientras 'ue los !atrones de conducta con alcance de objeto describen como un gru!o de objetos coo!eran !ara reali)ar una actividad 'ue un objeto no !uede reali)ar !or s solo. La tabla 7 muestra la clasificaci%n !ro!uesta !or 3amma de algunos de los !atrones ms utili)ados actualmente I3amma 8@J

Creacin )lase

Estructural

De Conducta Inter!rete Plantilla 1adena de 2es!onsabilida d 1omando Iterador Intermediario =bservador stado strategia Visitante Femoria

Ftodo de 0da!tador Fabricaci%n KclasesL Fbrica 1onstructor Prototi!o *ingleton 0da!tador KobjetosL Puente 1om!osici%n +ecorador Fachada Fl"#eight 0!oderado

O53eto

5abla 7. 1lasificaci%n de Patrones de +ise$o ,.!.1. E3e(%lo e %atrn e ise.o 1omo ejem!lo de !atr%n de dise$o se mostrar el !atr%n intermediario.

6
Laboratorio de *istemas de Informaci%n Facultad de Informtica Universidad Politcnica de Valencia

Patrn &ntermediario

ste !atr%n define un objeto 'ue enca!sula como un conjunto de objetos interaccionan. l intermediario facilita el aco!lamiento mnimo& evitando 'ue los objetos !artici!antes se tengan 'ue referenciar entre ellos e(!lcitamente & con lo 'ue se !ermite variar su interacci%n inde!endientemente. Los objetos !artici!antes solo conocen al intermediario. l desarrollo orientado a objetos !otencia el re!arto de conducta entre objetos. 5al re!arto !uede resultar en una ar'uitectura donde e(isten mHlti!les cone(iones entre los objetos. n el !eor de los casos cada objeto debera conocer a todos los dems. sto dificulta la reutili)aci%n. *e !uede evitar esta situaci%n& enca!sulando la conducta colectiva en un objeto llamado intermediario. Un intermediario es res!onsable de controlar " coordinar las interacciones de un gru!o de objetos. sto !uede ser Htil como se ver en el ejem!lo de interacciones entre elementos grficos. La estructura del !atr%n siguiendo la notaci%n =F5 !ara el diagrama de clases es como sigue,

Figura 7. Patr%n Intermediario

Un ejem!lo de utili)aci%n de este !atr%n es la im!lementaci%n de cajas de dialogo en una interfa) grfica . Una caja de dialogo utili)a una ventana !ara !resentar una colecci%n de elementos grficos tales como botones& menHs o cam!os de entrada. Frecuentemente e(isten de!endencias entre los elementos grficos en el dialogo. Por ejem!lo un 7
Laboratorio de *istemas de Informaci%n Facultad de Informtica Universidad Politcnica de Valencia

bot%n esta inhabilitado cuando cierto cam!o de entrada esta vaco. *eleccionando una entrada de una lista de o!ciones llamada una caja ti!o lista !odra cambiar los contenidos de un cam!o de entrada. *e !uede enca!sular esta conducta en un intermediario& llamado en el ejem!lo +irectorM+ialogo. s im!ortante resaltar los siguientes as!ectos,

1ada objeto de las clases !artici!antes es decir los objetos grficos de ti!o ListM/o( o ntr" MField solo conoce a su intermediario concreto . *iem!re 'ue un objeto grfico re'uiera comunicarse con otro ha de hacerlo a travs de su intermediario K+irectorM+ialogoL.

Figura N. jem!lo del Patr%n Intermediario 6. Patrones / co(%onentes 1abra a'u !reguntarse !or la diferencia entre patrones de dise$o " componentes . ncontramos en el mercado una serie de !roductos 'ue incor!oran un conjunto de elementos& denominados com!onentes " 'ue !ermiten construir de forma r!ida !artes de la a!licaci%n& en !articular la interfa) de usuario. La dis!onibilidad inmediata de botones& ventanas& menHs des!legables& etc hacen 'ue la construcci%n de una interfa) grfica sea desde un !unto de vista tcnico una tarea relativamente sencilla. Los !roblemas de interacci%n con el usuario " el nivel de usabilidad tienen 'ue ver con !roblemas de dise$o ms com!lejos 'ue con la construcci%n OfsicaO de la interfa). La diferencia fundamental con un !atr%n es 'ue el com!onente es una combinaci%n fija de objetos& 'ue se !uede instanciar mediante el arrastre desde un icono 'ue lo re!resenta " 'ue se incor!ora inmediatamente a la a!licaci%n 'ue se est constru"endo. sto significa 'ue se trata de clases 'ue combinan un conjunto de otras formando macroobjetos !ero 'ue estn integradas en la librera de clases suministrada con el !roducto. +e esta manera& se !ueden ir im!lementando nuevos com!onentes a los cuales se asociarn conos 'ue los 8
Laboratorio de *istemas de Informaci%n Facultad de Informtica Universidad Politcnica de Valencia

identifi'uen " 'ue !ermitan utili)arlos de la misma manera 'ue los suministrados originalmente con el !roducto. Los !atrones& !or su lado& no forman parte de ninguna librer+a de clases . *%lo son modelos de combinaci%n 'ue !ueden utili)arse en el momento 'ue se !resenta un !roblema similar al 'ue !retende dar soluci%n el !atr%n corres!ondiente. 0 lo sumo& " en una instalaci%n mu" bien organi)ada& !odran almacenarse en una base de datos a la cual accedemos cuando nos enfrentamos a las diversas decisiones de dise$o durante las fases de anlisis " de dise$o. 7. +escri%cin e %atrn / %lantillas e %atrones +e!endiendo del autor& del nivel de abstracci%n " de la !ublicaci%n misma se han !resentado varios formatos !ara enca!sular la informaci%n de un !atr%n. Los !untos ms significativos 'ue debe contener un !atr%n son, ;ombre, *ignificativo " corto& fcil de recordar " asociar a la informaci%n 'ue sigue Problema, Un enunciado 'ue describe las metas " objetivos buscados " el conte(to 1onte(to, +efine las !recondiciones en las cuales ocurren el !roblema " su soluci%n Fuer)as, +escri!ci%n de las fuer)as " restricciones relevantes en el !roblema " como interactHan o entran en conflicto *oluci%n, Las relaciones estticas " reglas dinmicas 'ue describen c%mo solucionar el !roblema jem!los, Uno o ms ejem!los 'ue ilustren el conte(to& el !roblema " su soluci%n 1onte(to 2esultante, l estado en el cual 'ueda el sistema des!us de a!licar el !atr%n " las consecuencias de hacerlo 2acionalidad, Una e(!licaci%n justificada de los !asos o reglas en el !atr%n 2elaciones, relaciones estticas " dinmicas del !atr%n con otros Usos conocidos, +escribe ocurrencias del !atr%n conocidas " su a!licaci%n dentro de los sistemas e(istentes La !ro!uesta de 3amma K788@L& !or ejem!lo& !ro!one 'ue los elementos esenciales de un !atr%n son los siguientes, 7. Un no(5re el %atrn. s una forma abreviada 'ue !ueda darnos una idea del !roblema al 'ue se a!lica& sus soluciones " consecuencias. 0l asignar un nombre& estamos facilitando la tarea de dise$o !uesto 'ue nos comunicamos a un ma"or nivel de abstracci%n. s bastante difcil encontrar nombres adecuados 'ue sirvan a este !ro!%sito.

9
Laboratorio de *istemas de Informaci%n Facultad de Informtica Universidad Politcnica de Valencia

N. l %ro5le(a describe cuando a!licar el !atr%n. 0'u se e(!lica el !roblema " su conte(to. Un a$adido Htil es el de las condiciones de a!licabilidad del !atr%n. P. La solucin describe los elementos 'ue constitu"en el dise$o& sus relaciones& res!onsabilidades " colaboraciones. *e insiste mucho en 'ue esta soluci%n es como una !lantilla 'ue !rovee una descri!ci%n abstracta de un !roblema de dise$o " c%mo una dis!osici%n general de elementos Ken este caso clases " objetosL !uede resolverlo. >. Las consecuencias son los resultados " com!romisos de a!licar el !atr%n. stos son los elementos esenciales& !ero cuando se trata de reali)ar una descri!ci%n concreta de un !atr%n& la !lantilla !ro!uesta estar com!uesta !or una serie de secciones 'ue !ermiten una estructura ms detallada 'ue la ofrecida !or la enumeraci%n de los elementos esenciales. *iguiendo a 3amma& encontramos la siguiente lista " descri!ci%n de secciones dentro de la !lantilla 'ue describe cada !atr%n. ste formato estructurado es Htil !uesto 'ue !ermite la se!araci%n semntica de lo 'ue !odra haber sido un te(to com!leto " !ermite adems su almacenamiento en una base de datos !ara su !osterior acceso si deseamos aumentar su reutili)aci%n. 7L ;ombre del Patr%n " 1lasificaci%n& NL Intenci%n PL 5ambin conocido como K*in%nimoL& >L Fotivaci%n& @L 0!licabilidad ?L structura& 9L Partici!antes& AL 1olaboraciones 8L 1onsecuencias& 7<L Im!lementaci%n 77L jem!lo de c%digo& 7NL Usos conocidos " Patrones relacionados

10
Laboratorio de *istemas de Informaci%n Facultad de Informtica Universidad Politcnica de Valencia