UNIVERSIDAD DE OVIEDO ESCUELA UNIVERSITARIA DE INGENIERA TCNICA EN INFORMTICA DE OVIEDO PROYECTO FIN DE CARRERA GUA DE CONSTRUCCIN DE SOFTWARE EN JAVA

CON PATRONES DE DISEO DIRECTOR: JUAN MANUEL CUEVA LOVELLE AUTOR: FRANCISCO JAVIER MARTNEZ JUAN VB del Director del Proyecto

GUA DE CONSTRUCCIN DE SOFTWARE EN JAVA CON PATRONES DE DISEO RESUMEN Se trata de una aplicacin, que de un modo didctico, sirva para la comprensin y util izacin de patrones de diseo de forma clara y correcta en la construccin de software. El proyecto est dividido en dos partes fundamentales: Una introduccin terica a los patrones de diseo. Ejemplos de aplicaciones utilizando patrones de diseo. El desarrollo del proyecto consiste en la utilizacin de patrones de diseo en la re alizacin de programas, con un fin didctico, explicando detalladamente los patrones utilizados , as como la implementacin de dichos ejemplos en uno de los ltimos lenguajes de programacin q ue han aparecido y que mayor futuro tienen, debido a sus numerosas ventajas, el len guaje Java. PALABRAS CLAVE Gua, Patrones de diseo, Lenguaje Java, Tecnologa Orientada a Objetos, Notacin UML, Software, Singleton, Iterator, Strategy, Observer, Prototype, Composite, Decorator, Factory Method, State, Template Method, Command, Adapter, Mediator, Null Object, JHotDraw.

GUIDE TO SOFTWARE CONSTRUCTION USING DESIGN PATTERNS IN JAVA ABSTRACT This is an application with a didactic purpose: be useful to the understanding a nd the use of design patterns -in a right and fair way- in the building of software. The project has two parts: An theoric introduction to design patterns. Examples of applications using design patterns. The development of the project consists in the use of design patterns in the mak ing of programs with a didactic purpose, explaining in detail the patterns used as well as the implementation of that examples in one of the lastest appeared and best-futured (due to its numerous advantages) programation languages: Java language. KEY WORDS Guide, Design patterns, Java language, Object-Oriented technology, UML notation, Software, Singleton, Iterator, Strategy, Observer, Prototype, Composite, Decorator, Factory Method, State, Template Method, Command, Adapter, Mediator, Null Object, JHotDraw.

TABLA DE CONTENIDOS 1. INTRODUCCIN................................................................... ................................................................................ ..1 1.1. JUSTIFICACIN................................................................ ...............................................................................1

1.2. INTRODUCCIN A LOS PATRONES.................................................. .........................................................2 1.2.1. Desarrollo histrico ...................................................... .........................................................................4 1.2.2. Patrones de software .................................................... ..........................................................................5 1.2.2.1. Definiciones........................................................... ............................................................................5 1.2.2.2. Caractersticas de los patrones software ................................ ......................................................6 1.2.2.3. Clases de patrones software............................................ ...............................................................7 1.3. PATRONES DE DISEO........................................................... .......................................................................8 1.3.1. Qu es un patrn de diseo?..................................................... ..........................................................9 1.3.2. Descripcin de patrones de diseo............................................ ....................................................... 10 1.3.3. Cualidades de un patrn de diseo............................................ ......................................................12 1.3.4. Clasificacin de los patrones de diseo...................................... ....................................................13 1.3.5. El catlogo de patrones de diseo ........................................... ........................................................ 15

1.3.6. Patrones de diseo, reglas y creatividad .................................. ...................................................... 23 1.3.7. Patrones y algoritmos.................................................... .....................................................................24 1.3.8. Patrones y frameworks.................................................... .................................................................... 25 1.3.9. Donde usar los patrones.................................................. ...................................................................26 1.3.10. Seleccionar un patrn de diseo............................................. .......................................................32 1.3.11. Como usar un patrn de diseo............................................... .......................................................33 1.3.12. El futuro de los patrones .............................................. ................................................................... 34 1.4. ANTIPATRONES............................................................... .............................................................................34 1.5. CONCLUSIN .................................................................. ...............................................................................3 6 2. EXPLICACIN DETALLADA DE LOS PATRONES DE DISEO UTILIZADOS EN LOS EJEMPLOS ................................................................................ ................................................................................ ....................... 37 2.1. SINGLETON [GOF95].......................................................... ............................................................................37 2.1.1. Objetivo................................................................. ................................................................................ . 37 2.1.2. Aplicabilidad............................................................ ............................................................................ 37 2.1.3. Solucin................................................................... .............................................................................. 3 7

2.1.4. Consecuencias............................................................ .......................................................................... 38 2.1.5. Implementacin ............................................................ ........................................................................ 38 2.1.6. Usos en el API de Java .................................................. ...................................................................... 38 2.1.7. Patrones relacionados.................................................... .................................................................... 39 2.2. ITERATOR [GOF95]........................................................... .............................................................................41 2.2.1. Objetivo................................................................. ................................................................................ . 41 2.2.2. Aplicabilidad............................................................ ............................................................................ 41 2.2.3. Solucin................................................................... .............................................................................. 4 1 2.2.4. Consecuencias............................................................ .......................................................................... 42 2.2.5. Implementacin ............................................................ ........................................................................ 42 2.2.6. Usos en el API de Java .................................................. ...................................................................... 43 2.2.7. Patrones relacionados.................................................... .................................................................... 43 2.3. STRATEGY [GOF95]........................................................... ............................................................................45 2.3.1. Objetivo................................................................. ................................................................................ . 45

2.3.2. Aplicabilidad............................................................ ............................................................................ 45 2.3.3. Solucin................................................................... .............................................................................. 4 5 2.3.4. Consecuencias............................................................ .......................................................................... 46 2.3.5. Implementacin ............................................................ ........................................................................ 46 2.3.6. Usos en el API de Java .................................................. ...................................................................... 47 2.3.7. Patrones relacionados.................................................... .................................................................... 47 i

2.4. OBSERVER [GOF95]........................................................... .............................................................................49 2.4.1. Objetivo................................................................. ................................................................................ . 49 2.4.2. Aplicabilidad............................................................ ............................................................................ 49 2.4.3. Solucin................................................................... .............................................................................. 4 9 2.4.4. Consecuencias............................................................ .......................................................................... 51 2.4.5. Implementacin ............................................................ ........................................................................ 52 2.4.6. Usos en el API de Java .................................................. ...................................................................... 53 2.4.7. Patrones relacionados.................................................... .................................................................... 54 2.5. PROTOTYPE [GOF95].......................................................... ...........................................................................55 2.5.1. Objetivo................................................................. ................................................................................ . 55 2.5.2. Aplicabilidad............................................................ ............................................................................ 55 2.5.3. Solucin................................................................... .............................................................................. 5 6 2.5.4. Consecuencias............................................................ .......................................................................... 56 2.5.5. Implementacin ............................................................ ........................................................................ 57

2.5.6. Usos en el API de Java .................................................. ...................................................................... 58 2.5.7. Patrones relacionados.................................................... .................................................................... 58 2.6. COMPOSITE [GOF95].......................................................... ...........................................................................59 2.6.1. Objetivo................................................................. ................................................................................ . 59 2.6.2. Aplicabilidad............................................................ ............................................................................ 59 2.6.3. Solucin................................................................... .............................................................................. 5 9 2.6.4. Consecuencias............................................................ .......................................................................... 61 2.6.5. Implementacin ............................................................ ........................................................................ 61 2.6.6. Usos en el API de Java .................................................. ...................................................................... 62 2.6.7. Patrones relacionados.................................................... .................................................................... 62 2.7. DECORATOR [GOF95].......................................................... .........................................................................65 2.7.1. Objetivo................................................................. ................................................................................ . 65 2.7.2. Aplicabilidad............................................................ ............................................................................ 65 2.7.3. Solucin................................................................... .............................................................................. 6 5

2.7.4. Consecuencias............................................................ .......................................................................... 66 2.7.5. Implementacin ............................................................ ........................................................................ 67 2.7.6. Patrones relacionados.................................................... .................................................................... 67 2.8. FACTORY METHOD [GOF95]..................................................... .................................................................69 2.8.1. Objetivo................................................................. ................................................................................ . 69 2.8.2. Aplicabilidad............................................................ ............................................................................ 69 2.8.3. Solucin................................................................... .............................................................................. 6 9 2.8.4. Consecuencias............................................................ .......................................................................... 71 2.8.5. Implementacin ............................................................ ........................................................................ 71 2.8.6. Usos en el API de Java .................................................. ...................................................................... 72 2.8.7. Patrones relacionados.................................................... .................................................................... 72 2.9. STATE [GOF95].............................................................. ................................................................................ .75 2.9.1. Objetivo................................................................. ................................................................................ . 75 2.9.2. Aplicabilidad............................................................ ............................................................................ 75

2.9.3. Solucin................................................................... .............................................................................. 7 5 2.9.4. Consecuencias............................................................ .......................................................................... 76 2.9.5. Implementacin ............................................................ ........................................................................ 77 2.9.6. Patrones relacionados.................................................... .................................................................... 77 2.10. TEMPLATE METHOD [GOF95]................................................... ..............................................................79 2.10.1. Objetivo................................................................ ................................................................................ 79 2.10.2. Aplicabilidad........................................................... ........................................................................... 79 2.10.3. Solucin.................................................................. ............................................................................. 79

2.10.4. Consecuencias........................................................... ......................................................................... 80 2.10.5. Implementacin............................................................ ......................................................................81 2.10.6. Patrones relacionados................................................... ................................................................... 81 2.11. COMMAND [GOF95]........................................................... ........................................................................83 2.11.1. Objetivo................................................................ ................................................................................ 83 2.11.2. Aplicabilidad........................................................... ........................................................................... 83

2.11.3. Solucin.................................................................. ............................................................................. 83

2.11.4. Consecuencias........................................................... ......................................................................... 84 ii

2.11.5. Implementacin............................................................ ...................................................................... 85 2.11.6. Usos en el API de Java.................................................. ....................................................................86 2.11.7. Patrones relacionados................................................... ................................................................... 86 2.12. ADAPTER [GOF95]........................................................... ............................................................................89 2.12.1. Objetivo................................................................ ................................................................................ 89 2.12.2. Aplicabilidad........................................................... ........................................................................... 89 2.12.3. Solucin.................................................................. ............................................................................. 89 2.12.4. Consecuencias........................................................... ......................................................................... 90 2.12.5. Implementacin............................................................ ...................................................................... 90 2.12.6. Usos en el API de Java.................................................. ....................................................................91 2.12.7. Patrones relacionados................................................... ................................................................... 93 2.13. MEDIATOR [GOF95].......................................................... ..........................................................................95 2.13.1. Objetivo................................................................ ................................................................................ 95 2.13.2. Aplicabilidad........................................................... ........................................................................... 95 2.13.3. Solucin.................................................................. ............................................................................. 95 2.13.4. Consecuencias........................................................... ......................................................................... 97 2.13.5. Implementacin............................................................ ...................................................................... 98 2.13.6. Usos en el API de Java.................................................. ....................................................................99 2.13.7. Patrones relacionados................................................... ................................................................... 99 2.14. NULL OBJECT [WOOLF97]..................................................... ..................................................................101 2.14.1. Objetivo................................................................ ..............................................................................10 1 2.14.2. Aplicabilidad........................................................... .........................................................................101 2.14.3. Solucin.................................................................. ...........................................................................101 2.14.4. Consecuencias........................................................... .......................................................................102 2.14.5. Implementacin............................................................ ....................................................................102 2.14.6. Patrones relacionados................................................... .................................................................103 3. EJEMPLOS DE APLICACIONES UTILIZANDO PATRONES DE DISEO......................... ..................105

3.1. APPLET PARA ESCUCHAR AUDIO................................................. .......................................................107 3.1.1. En qu consiste la aplicacin?................................................ ......................................................107 3.1.2. Patrones de diseo utilizados.............................................. ............................................................108 3.1.3. Diagrama de clases....................................................... .....................................................................108 3.1.4. Cdigo en Java............................................................. ......................................................................109 3.1.5. Funcionamiento de la aplicacin............................................ .......................................................112 3.2. LISTADOS DE FORMA ASCENDENTE Y DESCENDENTE DE UNA LISTA ................... ................115 3.2.1. En qu consiste la aplicacin?................................................ ......................................................115 3.2.2. Patrones de diseo utilizados.............................................. ............................................................116 3.2.3. Diagrama de clases....................................................... .....................................................................116 3.2.4. Cdigo en Java............................................................. ......................................................................117 3.2.5. Funcionamiento de la aplicacin............................................ .......................................................120 3.3. ORDENACIN DE UN VECTOR DE FORMA ASCENDENTE Y DESCENDENTE.................... ........121 3.3.1. En qu consiste la aplicacin?................................................ ......................................................121 3.3.2. Patrones de diseo utilizados.............................................. ............................................................122 3.3.3. Diagrama de clases....................................................... .....................................................................123 3.3.4. Cdigo en Java............................................................. ......................................................................123 3.3.5. Funcionamiento de la aplicacin............................................ .......................................................130 3.4. EJEMPLO VISUAL DEL PATRN OBSERVER........................................... ............................................133 3.4.1. En qu consiste la aplicacin?................................................ ......................................................133 3.4.2. Patrones de diseo utilizados.............................................. ............................................................134 3.4.3. Diagrama de clases....................................................... .....................................................................136 3.4.4. Cdigo en Java............................................................. ......................................................................137 3.4.5. Funcionamiento de la aplicacin............................................ .......................................................144 3.5. JHOTDRAW 5.1............................................................... .............................................................................145 3.5.1. En qu consiste la aplicacin?................................................ ......................................................145 3.5.2. Diagrama de clases general............................................... ..............................................................148 3.5.3. Patrones de diseo utilizados y cdigo en Java............................... ...........................................150 3.5.3.1. Abstracciones fundamentales ........................................... .........................................................151 3.5.3.2. Herramientas...........................................................

.......................................................................203 iii

3.5.3.3. Actualizacin de pantalla................................................ .............................................................216 3.5.3.4. Manipulacin de figuras.................................................. ............................................................238 3.5.3.5. Conexin de figuras ..................................................... .................................................................265 3.5.3.6. Entorno de ejecucin..................................................... ...............................................................283 3.5.3.7. Ms patrones de diseo..................................................... ..........................................................308 3.5.3.8. Conclusiones........................................................... ......................................................................337 3.5.4. Funcionamiento de la aplicacin............................................ .......................................................338 3.5.4.1. JavaDrawApp............................................................ ....................................................................338 3.5.4.2. JavaDrawApplet ........................................................ ...................................................................340 3.5.4.3. JavaDrawViewer......................................................... ...................................................................341 3.5.4.4. PertApp................................................................ ..........................................................................342 3.5.4.5. PertApplet............................................................. .........................................................................345 3.5.4.6. NothingApp ............................................................ ......................................................................345 3.5.4.7. NothingApplet.......................................................... ....................................................................348 3.5.4.8. NetApp................................................................. ..........................................................................349

4. CONCLUSIONES FINALES ........................................................ .....................................................................351 5. BIBLIOGRAFA................................................................... ...............................................................................3 53 ANEXO A: CDIGO COMPLETO EN JAVA DEL APARTADO 3.1.4............................... .........................355 CLASE MANEJADORAUDIO............................................................ ....................................................................355 CLASE AUDIOPLAYER............................................................... ..........................................................................357 PGINA WEB AUDIOPLAYER............................................................ .................................................................360 ANEXO B: CDIGO COMPLETO EN JAVA DEL APARTADO 3.2.4............................... .........................361 CLASE COLECCION................................................................. ..............................................................................36 1 CLASE LISTAITERATOR ............................................................ ..........................................................................362 CLASE DIALOGABOUT............................................................... .........................................................................365 ANEXO C: CDIGO COMPLETO EN JAVA DEL APARTADO 3.3.4............................... .........................369 INTERFACE ORDENACION ........................................................... .......................................................................369 CLASE ALGBURBUJAASC............................................................. .......................................................................369 CLASE ALGBURBUJADESC............................................................ ......................................................................370 CLASE ALGORITMOS................................................................ ...........................................................................371 CLASE COLECCION................................................................. ..............................................................................37 2 CLASE ORDENACIONSTRATEGY ....................................................... ................................................................374 CLASE DIALOGABOUT............................................................... .........................................................................378 ANEXO D: CDIGO COMPLETO EN JAVA DEL APARTADO 3.4.4............................... .........................381

CLASE VALOROBSERVABLE........................................................... .....................................................................381 CLASE TEXTOOBSERVADOR........................................................... ....................................................................383 CLASE BARRAOBSERVADOR........................................................... ....................................................................385 CLASE PATRONOBSERVER............................................................ ......................................................................388 CLASE DIALOGABOUT............................................................... .........................................................................390 ANEXO E: CDIGO COMPLETO EN JAVA DEL JHOTDRAW 5.1................................. ..........................393 PAQUETE CH.IFA.DRAW.UTIL........................................................ ...................................................................395 Interface Animatable ........................................................... .........................................................................395 Interface PaletteListener....................................................... .......................................................................396 Interface Storable.............................................................. ............................................................................396 Clase Clipboard ................................................................ ............................................................................397 Clase ColorMap.................................................................. ..........................................................................398 Clase Command................................................................... ..........................................................................400 Clase CommandButton............................................................. ...................................................................401 Clase CommandChoice............................................................. ...................................................................402 Clase CommandMenu .............................................................. ....................................................................403 Clase Filler.................................................................... ................................................................................ .405 iv

Clase FloatingTextField......................................................... .....................................................................406 Clase Geom...................................................................... ...............................................................................4 08 Clase IconKit .................................................................. ...............................................................................4 12 Clase PaletteButton............................................................. .........................................................................415 Clase PaletteIcon............................................................... ...........................................................................418 Clase PaletteLayout ............................................................ .........................................................................418 Clase ReverseVectorEnumerator................................................... ............................................................420 Clase StorableInput............................................................. .........................................................................421 Clase StorableOutput............................................................ .......................................................................424 PAQUETE CH.IFA.DRAW.FRAMEWORK................................................... .........................................................429 Interface ConnectionFigure...................................................... ..................................................................429 Interface Connector............................................................. .........................................................................432 Interface Drawing .............................................................. ...........................................................................434 Interface DrawingChangeListener................................................. ...........................................................438 Interface DrawingEditor......................................................... .....................................................................438 Interface DrawingView........................................................... .....................................................................440 Interface Figure................................................................ .............................................................................445 Interface FigureChangeListener.................................................. ..............................................................449 Interface FigureEnumeration..................................................... ................................................................450 Interface Handle................................................................ ............................................................................451 Interface Locator............................................................... ............................................................................453 Interface Painter............................................................... .............................................................................454 Interface PointConstrainer...................................................... ...................................................................455 Interface Tool.................................................................. ...............................................................................4 56 Clase DrawingChangeEvent ....................................................... ...............................................................458 Clase FigureChangeEvent......................................................... .................................................................458

Clase FigureSelection........................................................... .......................................................................459 Error HJDError.................................................................. ...........................................................................461 PAQUETE CH.IFA.DRAW.STANDARD.................................................... ............................................................463 Interface TextHolder............................................................ .........................................................................464 Clase AbstractConnector......................................................... ...................................................................465 Clase AbstractFigure ........................................................... ........................................................................467 Clase AbstractHandle ........................................................... .......................................................................474 Clase AbstractLocator........................................................... ......................................................................477 Clase AbstractTool ............................................................. ..........................................................................478 Clase ActionTool................................................................ ...........................................................................480 Clase AlignCommand.............................................................. .....................................................................481 Clase BoxHandleKit.............................................................. .......................................................................483 Clase BringToFrontCommand....................................................... ............................................................486 Clase BufferedUpdateStrategy ................................................... ................................................................487 Clase ChangeAttributeCommand.................................................... ..........................................................488 Clase ChangeConnectionEndHandle................................................. ......................................................489 Clase ChangeConnectionHandle.................................................... ..........................................................491 Clase ChangeConnectionStartHandle............................................... ......................................................494 Clase ChopBoxConnector.......................................................... .................................................................495 Clase CompositeFigure........................................................... ....................................................................496 Clase ConnectionHandle.......................................................... ..................................................................504 Clase ConnectionTool............................................................ .....................................................................507 Clase CopyCommand............................................................... ....................................................................512 Clase CreationTool ............................................................. .........................................................................513 Clase CutCommand................................................................ ......................................................................515 Clase DecoratorFigure........................................................... .....................................................................516 Clase DeleteCommand............................................................. ....................................................................521 Clase DragTracker .............................................................. .........................................................................522 Clase DuplicateCommand.......................................................... .................................................................523

Clase FigureChangeEventMulticaster.............................................. .......................................................524 Clase FigureEnumerator.......................................................... ...................................................................526 Clase FigureTransferCommand..................................................... ............................................................527 v

Clase GridConstrainer........................................................... ......................................................................528 Clase HandleTracker ............................................................ .......................................................................529 Clase LocatorConnector.......................................................... ...................................................................530 Clase LocatorHandle ............................................................ .......................................................................532 Clase NullHandle................................................................ ..........................................................................533 Clase OffsetLocator............................................................. ..........................................................................534 Clase PasteCommand.............................................................. .....................................................................536 Clase RelativeLocator........................................................... .......................................................................537 Clase ReverseFigureEnumerator................................................... ............................................................539 Clase SelectAreaTracker......................................................... ....................................................................540 Clase SelectionTool............................................................. .........................................................................542 Clase SendToBackCommand......................................................... .............................................................544 Clase SimpleUpdateStrategy...................................................... ................................................................545 Clase StandardDrawing........................................................... ...................................................................546 Clase StandardDrawingView....................................................... ..............................................................549 Clase ToggleGridCommand......................................................... ...............................................................562 Clase ToolButton ............................................................... ...........................................................................563 PAQUETE CH.IFA.DRAW.FIGURES..................................................... ................................................................565 Interface LineDecoration........................................................ .....................................................................565 Clase ArrowTip.................................................................. ............................................................................566 Clase AttributeFigure .......................................................... ........................................................................568 Clase BorderDecorator........................................................... .....................................................................571 Clase BorderTool................................................................ ..........................................................................573 Clase ChopEllipseConnector...................................................... ...............................................................574 Clase ConnectedTextTool ........................................................ ...................................................................574 Clase ElbowConnection........................................................... ...................................................................576 Clase ElbowHandle............................................................... .......................................................................577 Clase EllipseFigure............................................................. .........................................................................580 Clase FigureAttributes..........................................................

.......................................................................582 Clase FontSizeHandle............................................................ ......................................................................585 Clase GroupCommand.............................................................. ...................................................................586 Clase GroupFigure............................................................... ........................................................................587 Clase GroupHandle............................................................... .......................................................................588 Clase ImageFigure............................................................... .........................................................................589 Clase InsertImageCommand........................................................ ...............................................................592 Clase LineConnection............................................................ ......................................................................593 Clase LineFigure................................................................ ...........................................................................598 Clase NumberTextFigure.......................................................... ...................................................................600 Clase PolyLineConnector......................................................... ..................................................................601 Clase PolyLineFigure ........................................................... .......................................................................603 Clase PolyLineHandle............................................................ .....................................................................608 Clase PolyLineLocator........................................................... .....................................................................609 Clase RadiusHandle.............................................................. .......................................................................610 Clase RectangleFigure........................................................... .....................................................................611 Clase RoundRectangleFigure...................................................... ..............................................................613 Clase ScribbleTool ............................................................. ..........................................................................615 Clase ShortestDistanceConnector................................................. ............................................................617 Clase TextFigure................................................................ ...........................................................................620 Clase TextTool.................................................................. .............................................................................626 Clase UngroupCommand............................................................ ................................................................629 PAQUETE CH.IFA.DRAW.CONTRIB..................................................... ...............................................................631 Clase ChopPolygonConnector...................................................... ............................................................631 Clase DiamondFigure............................................................. .....................................................................632 Clase PolygonFigure ............................................................ .......................................................................633 Clase PolygonHandle ............................................................ ......................................................................642 Clase PolygonScaleHandle........................................................ ................................................................643 Clase PolygonTool .............................................................. .........................................................................645

Clase TriangleFigure............................................................ .......................................................................647 vi

Clase TriangleRotationHandle.................................................... ..............................................................650 PAQUETE CH.IFA.DRAW.APPLET ..................................................... ................................................................653 Clase DrawApplet................................................................ .........................................................................653 PAQUETE CH.IFA.DRAW.APPLICATION................................................. ..........................................................665 Clase DrawApplication........................................................... ....................................................................665 PAQUETE CH.IFA.DRAW.SAMPLES.JAVADRAW ........................................... ...................................................681 Clase AnimationDecorator........................................................ .................................................................681 Clase Animator.................................................................. ............................................................................683 Clase BouncingDrawing........................................................... ..................................................................684 Clase FollowURLTool............................................................. .....................................................................685 Clase JavaDrawApp............................................................... ......................................................................686 Clase JavaDrawApplet............................................................ ....................................................................690 Clase JavaDrawViewer............................................................ ....................................................................692 Clase MySelectionTool........................................................... .....................................................................694 Clase PatternPainter............................................................ ........................................................................695 Clase URLTool................................................................... ............................................................................696 PAQUETE CH.IFA.DRAW.SAMPLES.PERT ............................................... ..........................................................699 Clase PertApplet ............................................................... ............................................................................699 Clase PertApplication........................................................... .......................................................................700 Clase PertDependency............................................................ .....................................................................701 Clase PertFigure................................................................ ...........................................................................702 Clase PertFigureCreationTool ................................................... ...............................................................708 PAQUETE CH.IFA.DRAW.SAMPLES.NOTHING.............................................

.....................................................709 Clase NothingApp................................................................ .........................................................................709 Clase NothingApplet............................................................. .......................................................................710 PAQUETE CH.IFA.DRAW.SAMPLES.NET................................................. ..........................................................713 Clase NetApp ................................................................... ..............................................................................71 3 Clase NodeFigure................................................................ .........................................................................714 vii

Gua de construccin de software en Java con patrones de diseo 1. INTRODUCCIN 1.1. JUSTIFICACIN El desarrollo de software es una tarea complicada, la cual depende en gran medid a de la experiencia de las personas involucradas, en particular de los desarrolladores. 1. El 80% de los aportes vienen del 20% del personal. La comprensin del software es uno de los problemas ms complicados en la tarea de mantenimiento y evolucin. El hombre durante su historia ha dominado cierta tcnica pasando por un proceso: Se realizan las operaciones de una manera artesanal. Los expertos aprenden por u n proceso de ensayo y error y por transmisin de otros expertos. Se crea una ciencia alrededor de la tarea. Se desarrollan las tcnicas generalmente aceptadas en el rea. Se logra un conocimiento comn sobre cmo aplicar las tcnicas. Hay un metalenguaje comn ente los expertos. La sociedad requiere sistemas ms complejos y ms grandes. Los recursos para desarro llarlos cada vez son ms escasos. Debe existir un mecanismo de reutilizacin. 2. El 80% del esfuerzo esta en el 20% del cdigo desarrollado. Las Tecnologas Orientadas a Objetos son las ms utilizadas en los ltimos aos para el desarrollo de aplicaciones software. Se ha comprobado como este paradigma de programacin presenta muchas ventajas. Uno de los objetivos que se buscan al utilizar esta tcnica es conseguir la reutil izacin. Entre los beneficios que se consiguen con la reutilizacin estn: 1. Reduccin de tiempos. 2. Disminucin del esfuerzo de mantenimiento. 3. Eficiencia. 4. Consistencia. 5. Fiabilidad. 6. Proteccin de la inversin en desarrollos. Francisco Javier Martnez Juan Pgina 1

Gua de construccin de software en Java con patrones de diseo Este mecanismo de reutilizacin, segn el modelo de Objetos, debe afectar tanto al p ersonal (con una formacin constante a lo largo del tiempo) como a los diseos y especificac iones as como al cdigo fuente (mediante herencia, genericidad,...). Entre los diferentes mecanismos de reutilizacin estn: Componentes: elemento de software suficientemente pequeo para crearse y mantenerse pero suficientemente grande para poder utilizarse. Frameworks: bibliotecas de clases preparadas para la reutilizacin que pueden utilizar a su vez componentes. Objetos distribuidos: paradigma que distribuye los objetos de cooperacin a travs de una red heterognea y permite que los objetos interoperen como un todo unificad o. Patrones de diseo Sin embargo los mecanismos de reutilizacin tambin presentan algunos obstculos: 1. El sndrome No Inventado Aqu: los desarrolladores de software no se suelen fiar de lo que no est supervisado por ellos mismos. 2. Acceso a los fuentes de componentes y frameworks. 3. Impedimentos legales, comerciales o estratgicos. 4. Formato de distribucin de componentes (CORBA, ActiveX, ...). 5. Dilema entre reutilizar y rehacer. 6. Existe una inercia personal a los cambios. Basndonos en la regla de reutilizacin ( se debe ser consumidor de reutilizacin antes de ser un productor de reutilizacin ), este proyecto trata de ser una gua didctica de la uti lizacin de patrones de diseo en el desarrollo de aplicaciones. Como veremos en los siguie ntes puntos los patrones de diseo son un mecanismo de reutilizacin utilizado en la fase de diseo. Para poder comprender la utilizacin de los patrones se deben tener unos conocimie ntos fundamentales del modelo de Objetos. Por esta causa se dan por supuestos ciertos conceptos fundamentales de las Tecnologas Orientadas a Objetos (clase, objeto, encapsulacin, herencia, polimorfismo, agregacin, ...) que se van a utilizar en los siguientes p untos del tutorial de patrones de diseo. 1.2. INTRODUCCIN A LOS PATRONES Los patrones como elemento de la reutilizacin, comenzaron a utilizarse en la arqu itectura con el objetivo de reutilizar diseos que se haban aplicado en otras construcciones y q ue se catalogaron como completos. Chistopher Alexander fue el primero en intentar crear un formato especfico para p atrones en la arquitectura. Alexander argumenta que los mtodos comunes aplicados en la arqui tectura dan lugar a productos que no satisfacen las demandas y requerimientos de los usu

arios y son ineficientes a la hora de conseguir el propsito de todo diseo y esfuerzo de la ing eniera: mejorar la condicin humana. Alexander describe algunos diseos eternos para tratar de Francisco Javier Martnez Juan Pgina 2

Gua de construccin de software en Java con patrones de diseo conseguir sus metas. Propone, as, un paradigma para la arquitectura basado en tre s conceptos: la calidad, la puerta y el camino. La Calidad (la Calidad Sin Nombre): la esencia de todas las cosas vivas y tiles q ue nos hacen sentir vivos, nos da satisfaccin y mejora la condicin humana. La Puerta: el mecanismo que nos permite alcanzar la calidad. Se manifiesta como un lenguaje comn de patrones. La puerta es el conducto hacia la calidad. El Camino (El Camino Eterno): siguiendo el camino, se puede atravesar la puerta para llegar a la calidad. De este modo el patrn trata de extraer la esencia de ese diseo (lo que se puede ll amar la calidad sin nombre ) para que pueda ser utilizada por otros arquitectos cuando se enfrentan a problemas parecidos a los que resolvi dicho diseo. Alexander intenta resolver problemas arquitectnicos utilizando estos patrones. Pa ra ello trata de extraer la parte comn de los buenos diseos (que pueden ser dispares), con el ob jetivo de volver a utilizarse en otros diseos. Christopher Alexander da la siguiente definicin de patrn: 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 d e la misma forma . 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 e sencia del diseo se ha copiado de una construccin a otra, y a esta esencia se pliegan de form a natural los diversos requisitos. Dirase aqu que existe un patrn que soluciona de forma simp le y efectiva los problemas de construccin en tal zona. Se puede utilizar una metfora textil para explicar lo que es un patrn: es como la pieza que utiliza el sastre a la hora de confeccionar vestidos y trajes. De esta forma est e patrn adems de contener las especificaciones de corte y confeccin del producto final, represe nta a la vez, una parte de ese producto.

En definitiva se puede definir un patrn como una solucin a un problema en un determinado contexto . Francisco Javier Martnez Juan Pgina 3

Gua de construccin de software en Java con patrones de diseo 1.2.1. Desarrollo histrico El trmino patrn se utiliza inicialmente en el campo de la arquitectura, por Christ opher Alexander, a finales de los 70 s. Este conocimiento es transportado al mbito del de sarrollo de software orientado a objetos y se aplica al diseo. De all es extrapolado al des arrollo en general y a las dems etapas. Desde 1964 hasta 1979 Christopher Alexander escribe varios libros acerca del pla neamiento urbano y la construccin de edificios. Entre sus libros estn: A pattern Language: Towns/Building/Construction de Christopher Alexander, Sara Ishikawa, Murria silverstein, Max Jacobson, Ingrid Fiksdahl-King y Shlomo Angel, 1977, Oxford University Press. 253 patrones, con el formato especfico propuesto por Alexander, se dan cita en este texto, en el que adems se propugna u na integracin del mejor-vivir con el medio fsico circundante: gente-patrones-gente. Cuando se habla del libro de Alexander o del libro AIS (las iniciales de los primeros autores) se refieren a esta obra. The Timeless Way of Building en 1979. En 1987, Ward Cunningham y Kent Beck trabajaron con Smaltalk y disearon interface s de usuario. Decidieron, para ello, utilizar alguna de las ideas de Alexander para d esarrollar un lenguaje pequeo de patrones para servir de gua a los programadores de Smaltalk. As dieron lugar al libro Using Pattern Languajes for Object-Oriented Programs . Poco despus, Jim Coplien comenz a realizar un catlogo de idioms (que son un tipo de patrones) en C++ y publica su libro 1991. Advanced C++ Programming Styles and Idioms en

Desde 1990 a 1994, Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides (el grupo de los cuatro) realizaron un primer catlogo de patrones de diseo. Posteriormente hubo diferentes discusiones a cerca de los patrones en las que pa rticiparon notables personalidades de los patrones. Poco despus de Abril de 1994 el libro Design Patterns: Elements of Reusable Object Oriented Software (Gang of Four, [GoF]) es publicado. En 1997 Brad Appleton publica Patterns and Software: Essential Concepts and Terminology . Mark Grand publica en 1998 Patterns in Java (volume 1) que es un catlogo de patrones de diseo ilustrados con UML. En 1999 el mismo autor publica Patterns in J ava (volume 2) en donde se aaden algunos patrones de diseo ms y otros tipos de patrones tales como patrones de organizacin de cdigo, patrones de optimizacin de cdigo, etc. Francisco Javier Martnez Juan Pgina 4

Gua de construccin de software en Java con patrones de diseo 1.2.2. Patrones de software Los patrones para el desarrollo de software son uno de los ltimos avances de la T ecnologa Orientada a Objetos. Los patrones son una forma literaria para resolver problema s de ingeniera del software, que tienen sus races en los patrones de la arquitectura. Los diseadores y analistas de software ms experimentados aplican de forma intuitiv a algunos criterios que solucionan los problemas de manera elegante y efectiva. La ingeniera del software se enfrenta a problemas variados que hay que identificar para poder uti lizar la misma solucin (aunque matizada) con problemas similares. Por otra parte, las metodologas Orientadas a Objetos tienen como uno de sus princ ipios no reinventar la rueda para la resolucin de diferentes problemas. Por lo tanto los pa trones se convierten en una parte muy importante en las Tecnologas Orientadas a Objetos par a poder conseguir la reutilizacin. La ingeniera del software, tomando conceptos aplicados por primera vez en arquite ctura, intenta construir patrones software para la resolucin de problemas en dicho campo . Para conseguir esto debe existir una comunicacin entre los distintos ingenieros para c ompartir los resultados obtenidos. Por tanto debe existir tambin un esquema de documentacin con el objetivo de que la comunicacin pueda entenderse de forma correcta. Esta comunicac in no se debe reducir a la implementacin, ya que nicamente fomenta el uso del cortar y pe gar . Pueden referirse a distintos niveles de abstraccin, desde un proceso de desarroll o hasta la utilizacin eficiente de un lenguaje de programacin. El objetivo de los patrones es crear un lenguaje comn a una comunidad de desarrol ladores para comunicar experiencia sobre los problemas y sus soluciones. 1.2.2.1. Definiciones Los diferentes autores han dado diversas definiciones de lo que es un patrn softw are. Veamos a continuacin alguna de ellas: 1. Dirk Riehle y Heinz Zullighoven: Un patrn es la abstraccin de una forma concreta que puede repetirse en contextos especficos. 2. Otras definiciones ms aceptadas por la comunidad software son: Un patrn es una informacin que captura la estructura esencial y la perspicacia de una familia de soluciones probadas con xito para un problema repetitivo que surge en un cierto contexto y sistema. Un patrn es una unidad de informacin nombrada, instructiva e intuitiva que

captura la esencia de una familia exitosa de soluciones probadas a un problema recurrente dentro de un cierto contexto. Francisco Javier Martnez Juan Pgina 5

Gua de construccin de software en Java con patrones de diseo 3. Segn Richard Gabriel: Cada patrn es una regla de tres partes, la cual expresa una relacin entre un cierto contexto, un conjunto de fuerzas que ocurren repetidamente en ese contexto y una cierta configuracin software que permite a estas fuerzas resolverse por si mismas. Esta definicin es similar a la dada por Alexander: Cada patrn es una relacin entre un cierto contexto, un problema y una solucin. El patrn es, resumiendo, al mismo tiempo una cosa que tiene su lugar en el mundo, y la regla que nos dice cmo crear esa cosa y cundo debemos crearla. Es al mismo tiempo una cosa y un proceso; al mismo tiempo una descripcin que tiene vida y una descripcin del proceso que la gener. 1.2.2.2. Caractersticas de los patrones software Hay que tener en cuenta que no todas las soluciones que tengan, en principio, la s caractersticas de un patrn son un patrn, sino que debe probarse que es una solucin a un problema que se repite. Para que se pueda considerar un patrn, ste debe pasar por unas pruebas que reciben el nombre de test de patrones. Mientras tanto esa solucin rec ibe el nombre de proto-patrn. Segn Jim Coplien los buenos patrones deben tener las siguientes caractersticas: Solucionar un problema: los patrones capturan soluciones, no slo principios o estrategias abstractas. Ser un concepto probado: los patrones capturan soluciones demostradas, no teoras o especulaciones. La solucin no es obvia: muchas tcnicas de solucin de problemas tratan de hallar soluciones por medio de principios bsicos. Los mejores patrones generan una solucin a un problema de forma indirecta. Describe participantes y relaciones entre ellos: los patrones no slo describen mdulos sino estructuras del sistema y mecanismos ms complejos. El patrn tiene un componente humano significativo: todo software proporciona a los seres humanos confort o calidad de vida (esttica y utilidad). Los patrones indican repeticin, si algo no se repite, no es posible que sea un pa trn. Pero la repeticin no es la nica caracterstica importante. Tambin necesitamos mostrar que un patrn se adapta para poder usarlo, y que es til. La repeticin es una caracterstica cuantitativa pura, la adaptabilidad y utilidad son caractersticas cualitativas. P odemos mostrar la repeticin simplemente aplicando la regla de tres (en al menos tres sis temas existentes); mostrar la adaptabilidad explicando como el patrn es exitoso; y most rar la utilidad explicando porque es exitoso y beneficioso. As que aparte de la repeticin, un patrn debe describir como la solucin salda o resue lve sus objetivos, y porque est es una buena solucin. Se puede decir que un patrn es do nde la Francisco Javier Martnez Juan Pgina 6

Gua de construccin de software en Java con patrones de diseo teora y la prctica se juntan para fortalecerse y complementarse, para mostrar que la estructura que describe es til, utilizable y usada. Un patrn debe ser til porque ensea como el patrn que tenemos en nuestra mente puede ser transformado en una instancia del patrn en el mundo real, como una cosa que aa de valor a nuestra vida como diseadores. Un patrn debe ser tambin utilizable porque muestra como un patrn descrito de una forma literaria puede ser transformado en u n patrn que tenemos en nuestra mente. Y un patrn debe ser usado porque es como los patron es que existen en el mundo real llegan a ser documentados como patrones de una forma li teraria. Esto potencia una continua repeticin del ciclo desde los escritores de patrones, a los lectores de patrones, y a los usuarios de patrones: los escritores documentan los patrone s de forma literaria hacindolos utilizables para los lectores de patrones, quienes pueden re cordarlos en sus mentes, lo cual los hace ser tiles para los diseadores, quienes pueden usarlos en el mundo real, y mejorar la calidad de vida de los usuarios. 1.2.2.3. Clases de patrones software Existen diferentes mbitos dentro de la ingeniera del software donde se pueden apli car los patrones: 1. Patrones de arquitectura: expresa una organizacin o esquema estructural fundamental para sistemas software. Proporciona un conjunto de subsistemas predefinidos, especifica sus responsabilidades, e incluye una gua para organizar las relaciones entre ellos. 2. Patrones de diseo: proporciona un esquema para refinar los subsistemas o componentes de un sistema software, o las relaciones entre ellos. Describe estructuras repetitivas de comunicar componentes que resuelven un problema de diseo en un contexto particular. 3. Patrones de programacin (Idioms patterns): un idioma es un patrn de bajo nivel de un lenguaje de programacin especfico. Describe como implementar aspectos de componentes o de las relaciones entre ellos utilizando las facilidad es del lenguaje de programacin dado. 4. Patrones de anlisis: describen un conjunto de prcticas que aseguran la obtencin de un buen modelo de un problema y su solucin. 5. Patrones organizacionales: describen la estructura y prcticas de las organizaciones humanas, especialmente en las que producen, usan o administran software. La diferencia entre estas clases de patrones est en los diferentes niveles de abs traccin y detalle, y del contexto particular en el cual se aplican o de la etapa en el pro

ceso de desarrollo. As, los patrones de arquitectura son estrategias de alto nivel que in volucran a los componentes, las propiedades y mecanismos globales de un sistema. Los patrones d e diseo son tcticas de media escala relacionados con la estructura y el comportamiento de entidades y sus relaciones. No influyen sobre toda la estructura del sistema, pero define micro Francisco Javier Martnez Juan Pgina 7

Gua de construccin de software en Java con patrones de diseo arquitecturas de subsistemas y componentes. Los patrones de programacin son especf icos de las tcnicas de un lenguaje de programacin que afectan a partes pequeas del comportamiento de los componentes de un sistema. Los patrones de anlisis se refie ren a la etapa de anlisis del ciclo de vida de construccin de software. Los patrones organi zacionales describen la estructuracin del personal en el desarrollo de software. Tambin se puede hablar de otros tipos de patrones software, como pueden ser: 1. Patrones de programacin concurrente. 2. Patrones de interfaz grfica. 3. Patrones de organizacin del cdigo. 4. Patrones de optimizacin de cdigo. 5. Patrones de robustez de cdigo. 6. Patrones de la fase de prueba. Entre las ventajas que se pueden citar de la utilizacin de patrones estn: 1. Facilitan la comunicacin interna. 2. Ahorran tiempo y experimentos intiles. 3. Mejoran la calidad del diseo y la implementacin. 4. Son como normas de productividad . 5. Facilitan el aprendizaje de los paquetes Java. 1.3. PATRONES DE DISEO Una cosa que los diseadores expertos no hacen es resolver cada problema desde el principio. A menudo reutilizan las soluciones que ellos han obtenido en el pasad o. Cuando encuentran una buena solucin, utilizan esta solucin una y otra vez. Consecuentemen te tu podras encontrar patrones de clases y comunicaciones entre objetos en muchos sist emas orientados a objetos. Estos patrones solucionan problemas especficos del diseo y h acen los diseos orientados a objetos ms flexibles, elegantes y por ltimo reutilizables. Los patrones de diseo ayudan a los diseadores a reutilizar con xito diseos para obtener nuevos diseos. Un diseador que conoce algunos patrones puede aplicarlos inmediatamente a problemas de diseo sin tener que descubrirlos. El valor de la experiencia en los diseos es muy importante. Cuando tienes que hac er un diseo que crees que ya has solucionado antes pero no sabes exactamente cuando o c omo lo hiciste. Si pudieras recordar los detalles de los problemas anteriores y como lo s solucionaste, entonces podras reutilizar la experiencia en vez de tener que volver a pensarlo. El objetivo de los patrones de diseo es guardar la experiencia en diseos de progra mas orientados a objetos. Cada patrn de diseo nombra, explica y evala un importante dis eo en los sistemas orientados a objetos. Es decir se trata de agrupar la experienci a en diseo de una forma que la gente pueda utilizarlos con efectividad. Por eso se han documen tado los mas importantes patrones de diseo y presentado en catlogos.

Francisco Javier Martnez Juan Pgina 8

Gua de construccin de software en Java con patrones de diseo Los patrones de diseo hacen ms fcil reutilizar con xito los diseos y arquitecturas. Expresando estas tcnicas verificadas como patrones de diseo se hacen ms accesibles para los diseadores de nuevos sistemas. Los patrones de diseo te ayudan a elegir diseos alternativos que hacen un sistema reutilizable y evitan alternativas que comprom etan la reutilizacin. Los patrones de diseo pueden incluso mejorar la documentacin y mantenimiento de sistemas existentes. Es decir, los patrones de diseo ayudan a un diseador a conseguir un diseo correcto rpidamente. 1.3.1. Qu es un patrn de diseo? Christopher Alexander dice: 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 . Los trabajos de Alexander intentan identificar y resolver, en un marco descripti vo formal aunque no exacto, problemas esenciales en el dominio de la arquitectura. A los d iseadores de software les ha parecido trasladar muchas de las ideas de Alexander al domini o software. En software las soluciones son expresadas en trminos de objetos e interfaces en l ugar de paredes y puertas, pero el ncleo de ambos tipos de patrones es una solucin a un pr oblema en un contexto. Alexander ha servido, en realidad, de catalizador de ciertas tendencias ivas utilizadas en el diseo de sistemas software. En general, un patrn tiene cuatro elementos esenciales: 1. El nombre del patrn se utiliza para describir un problema de diseo, su solucin, y consecuencias en una o dos palabras. Nombrar un patrn incrementa inmediatamente nuestro vocabulario de diseo. Esto nos permite diseos a un alto nivel de abstraccin. Tener un vocabulario de patrones nos permite hablar sobre ellos con nuestros amigos, en nuestra documentacin, e incluso a nosotros mismos. 2. El problema describe cuando aplicar el patrn. Se explica el problema y su contexto. Esto podra describir problemas de diseo especficos tales como algoritmos como objetos. Podra describir estructuras de clases o objetos que son sintomticas de un diseo inflexible. Algunas veces el problema incluir una lista de condiciones que deben cumplirse para poder aplicar el patrn. 3. La solucin describe los elementos que forma el diseo, sus relaciones, responsabilidades y colaboraciones. La solucin no describe un diseo particular o implementacin, porque un patrn es como una plantilla que puede ser aplicada en diferentes situaciones. En cambio, los patrones proveen una descripcin Francisco Javier Martnez Juan Pgina 9 construct

Gua de construccin de software en Java con patrones de diseo abstracta de un problema de diseo y como una disposicin general de los elementos (clases y objetos en nuestro caso) lo soluciona. 4. Las consecuencias son los resultados de aplicar el patrn. Estas son muy importantes para la evaluacin de diseos alternativos y para comprender los costes y beneficios de la aplicacin del patrn. Los patrones de diseo tienen un cierto nivel de abstraccin. Los patrones de diseo n o son diseos tales como la realizacin de listas y tablas hash que pueden ser codificadas en clases y reutilizadas. Un algoritmo puede ser un ejemplo de implementacin de un patrn, pero es demasiado incompleto, especfico y rgido para ser un patrn. Una regla o heurstica pue de participar en los efectos de un patrn, pero un patrn es mucho ms. Los patrones de d iseo son descripciones de las comunicaciones de objetos y clases que son personalizad as para resolver un problema general de diseo en un contexto particular. Un patrn de diseo nombra, abstrae e identifica los aspectos clave de un diseo estructurado, comn, que lo hace til para la creacin de diseos orientados a objetos reutilizables. Los patrones de diseo identifican las clases participantes y las i nstancias, sus papeles y colaboraciones, y la distribucin de responsabilidades. Cada patrn de dis eo se enfoca sobre un particular diseo orientado a objetos. Se describe cuando se aplic a, las caractersticas de otros diseos y las consecuencias y ventajas de su uso. Los patrones de diseo se pueden utilizar en cualquier lenguaje de programacin orie ntado a objetos, adaptando los diseos generales a las caractersticas de la implementacin pa rticular. 1.3.2. Descripcin de patrones de diseo Cmo describimos los patrones de diseo? Las notaciones grficas, aunque importantes y tiles, no son suficientes. Ests solo recogen el producto final del proceso de diseo como las relaciones entre clases y objetos. Para reutilizar el diseo, nosotros debemos tam bin guardar las decisiones, alternativas y ventajas que nos llevaron a ese diseo. Los ejemplo s concretos son tambin muy importantes, porque ellos nos ayudan a ver el funcionamiento del d iseo. Para describir los patrones de diseo se utiliza un formato consistente. Cada patrn es dividido en secciones de acuerdo con la siguiente plantilla. La plantilla nos mu estra una estructura uniforme para la informacin, de tal forma que los patrones de diseo sea n fciles de aprender, comparar y utilizar. 1. Nombre del patrn

Esta seccin consiste de un nombre del patrn y una referencia bibliografa que indica de donde procede el patrn. El nombre es significativo y corto, fcil de recordar y asociar a la informacin que sigue. Francisco Javier Martnez Juan Pgina 10

Gua de construccin de software en Java con patrones de diseo 2. Objetivo Esta seccin contiene unas pocas frases describiendo el patrn. El objetivo aporta la esencia de la solucin que es proporcionada por el patrn. El objetivo esta dirigido a programadores con experiencia que pueden reconocer el patrn como uno que ellos ya conocen, pero para el cual ellos no le han dado un nombre. Despus de reconocer el patrn por su nombre y objetivo, esto podra ser suficiente para comprender el resto de la descripcin del patrn. 3. Contexto La seccin de Contexto describe el problema que el patrn soluciona. Este problema suele ser introducido en trminos de un ejemplo concreto. Despus de presentar el problema en el ejemplo, la seccin de Contexto sugiere una solucin de diseo a ese problema. 4. Aplicabilidad La seccin Aplicabilidad resume las consideraciones que guan a la solucin general presentada en la seccin Solucin. En que situaciones es aplicable el patrn. 5. Solucin La seccin Solucin es el ncleo del patrn. Se describe una solucin general al problema que el patrn soluciona. Esta descripcin puede incluir, diagramas y texto que identifique la estructura del patrn, sus participantes y sus colaboraciones para mostrar como se soluciona el problema. Debe describir tanto la estructura dinmica como el comportamiento esttico. 6. Consecuencias La seccin Consecuencias explica las implicaciones, buenas y malas, del uso de la solucin. 7. Implementacin La seccin de Implementacin describe las consideraciones importantes que se han de tener en cuenta cuando se codifica la solucin. Tambin puede contener algunas variaciones o simplificaciones de la solucin. Francisco Javier Martnez Juan Pgina 11

Gua de construccin de software en Java con patrones de diseo 8. Usos en el API de Java Cuando hay un ejemplo apropiado del patrn en el ncleo del API de Java es comentado en esta seccin. Los patrones que no se utilizan en el ncleo del API de Java no contienen esta seccin. 9. Cdigo del ejemplo Esta seccin contiene el cdigo del ejemplo que ensea una muestra de la implementacin para un diseo que utiliza el patrn. En la mayora de estos casos, este ser el diseo descrito en la seccin de Contexto. 10. Patrones relacionados Esta seccin contiene una lista de los patrones que estn relacionados con el patrn que se describe. 1.3.3. Cualidades de un patrn de diseo En adicin a los elementos mencionados anteriormente, un buen escritor de patrones expuso varias cualidades deseables. Doug Lea, en su libro Christopher Alexander: an Introduction for Object-Oriented Designers muestra una descripcin detallada de est as cualidades, las cuales son resumidas a continuacin: Encapsulacin y abstraccin: cada patrn encapsula un problema bien definido y su solucin en un dominio particular. Los patrones deberan de proporcionar lmites claros que ayuden a cristalizar el entorno del problema y el entorno de la soluc in empaquetados en un entramado distinto, con fragmentos interconectados. Los patrones tambin sirven como abstracciones las cuales contienen dominios conocidos y experiencia, y podran ocurrir en distintos niveles jerrquicos de granularidad conceptual. Extensin y variabilidad: cada patrn debera ser abierto por extensin o parametrizacin por otros patrones, de tal forma que pueden aplicarse juntos para solucionar un gran problema. Un patrn solucin debera ser tambin capaz de realizar un variedad infinita de implementaciones (de forma individual, y tambin en conjun cin con otros patrones). Generatividad y composicin: cada patrn, una vez aplicado, genera un contexto resultante, el cual concuerda con el contexto inicial de uno o ms de uno de los patrones del catlogo. Est subsecuencia de patrones podra luego ser aplicada progresivamente para conseguir el objetivo final de generacin de un todo o solucin completa. Los patrones son aplicados por el principio de evolucin fragmentada. Pero los patrones no son simplemente de naturaleza lineal, ms bien e sos Francisco Javier Martnez Juan Pgina 12

Gua de construccin de software en Java con patrones de diseo patrones en un nivel particular de abstraccin y granularidad podran guiar hacia o ser compuestos con otros patrones para modificar niveles de escala. Equilibrio: cada patrn debe realizar algn tipo de balance entre sus efectos y restricciones. Esto podra ser debido a uno o ms de un heurstico que son utilizados para minimizar el conflicto sin el contexto de la solucin. Las invariaciones representadas en un problema subyacente solucionan el principio o filosofa para e l dominio particular, y proveen una razn fundamental para cada paso o regla en el patrn. El objetivo es este, si esta bien escrito, cada patrn describe un todo que es ms g rande que la suma de sus partes, debido a la acertada coreografa de sus elementos trabajand o juntos para satisfacer todas sus variaciones reclamadas. 1.3.4. Clasificacin de los patrones de diseo Dado que hay muchos patrones de diseo necesitamos un modo de organizarlos. En est a seccin clasificamos los patrones de diseo de tal forma que podamos referirnos a fa milias de patrones relacionados. La clasificacin nos ayuda a saber lo que hace un patrn. Segn el libro Patterns in Java (Volume 1) existen seis categoras: PATRONES DE DISEO FUNDAMENTALES Los patrones de esta categora son los ms fundamentales e importantes patrones de d iseo conocidos. Estos patrones son utilizados extensivamente en otros patrones de dis eo. PATRONES DE CREACIN Los patrones de creacin muestran la gua de cmo crear objetos cuando sus creaciones requieren tomar decisiones. Estas decisiones normalmente sern resueltas dinmicamen te decidiendo que clases instanciar o sobre que objetos un objeto delegar responsabi lidades. La vala de los patrones de creacin nos dice como estructurar y encapsular estas de cisiones. A menudo hay varios patrones de creacin que puedes aplicar en una situacin. Alguna s veces se pueden combinar mltiples patrones ventajosamente. En otros casos se debe elegir entre los patrones que compiten. Por estas razones es importante conocer los sei s patrones descritos en esta categora. PATRONES DE PARTICIN

En la etapa de anlisis, tu examirobbll problema para identificar los actores, cas os de uso, requerimientos y las relaciones que constituyen el problema. Los patrones de est a categora proveen la gua sobre como dividir actores complejos y casos de uso en mltiples cla ses. Francisco Javier Martnez Juan Pgina 13

Gua de construccin de software en Java con patrones de diseo PATRONES ESTRUCTURALES Los patrones de esta categora describen las formas comunes en que diferentes tipo s de objetos pueden ser organizados para trabajar unos con otros. PATRONES DE COMPORTAMIENTO Los patrones de este tipo son utilizados para organizar, manejar y combinar comp ortamientos. PATRONES DE CONCURRENCIA Los patrones de esta categora permiten coordinar las operaciones concurrentes. Es tos patrones se dirigen principalmente a dos tipos diferentes de problemas: 1. Recursos compartidos: Cuando las operaciones concurrentes acceden a los mismos datos o otros tipos de recursos compartidos, podra darse la posibilidad de que las operaciones interfirieran unas con otras si ellas acceden a los recursos al mismo tiempo. Para garantizar que cada operacin se ejecuta correctamente, la operacin debe ser protegida para acceder a los recursos compartidos en solitario. Sin embargo, si las operaciones estn completamente protegidas, entonces podran bloquearse y no ser capaces de finalizar su ejecucin. El bloqueo es una situacin en la cual una operacin espera por otra para realizar algo antes de que esta proceda. Porque cada operacin esta esperando por la otra para hacer algo, entonces ambas esperan para siempre y nunca hacen nada. 2. Secuencia de operaciones: Si las operaciones son protegidas para acceder a un recurso compartido una cada vez, entonces podra ser necesario garantizar que ellas acceden a los recursos compartidos en un orden particular. Por ejemplo, un objeto nunca ser borrado de una estructura de datos antes de que est sea aadido a la estructura de datos. Francisco Javier Martnez Juan Pgina 14

Gua de construccin de software en Java con patrones de diseo Fundamentales De creacin De Particin Estructurales De comportamiento De Concurrencia Delegation (When Not to Use Inheritance) Factory Method Layered Initialization Adapter Chain of Responsibility Single Threaded Execution Interface Abstract Factory Filter Iterator Command Guarded Suspension Immutable Builder Composite Bridge Little Language Balking Marker Interface Prototype Facade Mediator Scheduler Proxy Singleton Flyweight Snapshot Read/Write Lock Object Pool Dynamic Linkage Observer ProducerConsumer Virtual Proxy State Two-Phase Termination Decorator Null Object Cache Management Strategy Template Method Visitor 1.3.5. El catlogo de patrones de diseo Si aceptamos que los patrones pueden resultar tiles en el desarrollo de software, el siguiente paso es reunirlos en catlogos de forma que resulten accesibles mediante distintos criterios, pues lo que necesitamos no es tan slo la completa descripcin de cada uno de los pa trones sino, esencialmente, la correspondencia entre un problema real y un patrn (o conj unto de patrones) determinado. Lo que se pretende con un catlogo de patrones no es favorecer al diseador experto (que quizs no necesite en absoluto de los patrones), sino ms bien ayudar al diseador ine

xperto a adquirir con cierta rapidez las habilidades de aqul, como tambin comunicar al posi ble cliente, si es el caso, las decisiones de diseo de forma clara y autosuficiente. Un catlogo de patrones es un medio para comunicar la experiencia de forma efectiv a, reduciendo lo que se conoce como curva de aprendizaje del diseo. Francisco Javier Martnez Juan Pgina 15

Gua de construccin de software en Java con patrones de diseo A continuacin se exponen los 41 patrones de diseo que contiene el libro Patterns in Java (Volumen 1) clasificados por categoras poniendo el nombre del patrn, seguido de una referencia bibliogrfica (entre corchetes) que indica de donde procede el patrn y s u objetivo: PATRONES DE DISEO FUNDAMENTALES Los patrones de esta categora son los ms fundamentales e importantes patrones de d iseo conocidos. Estos patrones son utilizados extensivamente en otros patrones de dis eo. Delegation: (When Not to Use Inheritance) [Grand98] Es una forma de extender y reutilizar las funcionalidades de una clase escribien do una clase adicional con funcionalidad aadida que utiliza instancias de la clase original qu e suministra las funcionalidades originales. Interface [Grand98] Mantiene una clase que utiliza datos y servicios suministrados por instancias de otras clases independientes teniendo acceso a estas instancias a travs de un interface. Immutable [Grand98] Incrementa la robustez de los objetos que comparten referencias a los mismos obj etos y reduce el alto acceso concurrente a un objeto. Prohbe que ninguna informacin del e stado de los objetos cambie despus de que el objeto es construido. El patrn Immutable tambin evita la necesidad de sincronizar mltiples hilos de ejecucin que comparten un objeto. Marker Interface [Grand98] Utiliza interfaces que no declaran mtodos o variables que indiquen la semntica de los atributos de una clase. Esto funciona particularmente bien con utilidades de cla ses que deben determinar algo acerca de los objetos sin asumir que ellos son una instancia de alguna clase particular. Proxy [GoF95] Es un patrn muy general que ocurre en muchos otros patrones, pero nunca l mismo en su puro estado. El patrn Proxy hace llamadas a mtodos de un objeto que ocurre indirectamente a travs de un objeto proxy que acta como un sustituto para otro obj eto, delegando las llamadas a mtodos a ese objeto. Las clases para los objetos proxy s on

declaradas de una forma que normalmente eliminan el conocimiento de los objetos del cliente que son tratados con un proxy. Es decir, este patrn provee un representante de ac ceso a otro objeto. Francisco Javier Martnez Juan Pgina 16

Gua de construccin de software en Java con patrones de diseo PATRONES DE CREACIN Los patrones de creacin muestran la gua de cmo crear objetos cuando sus creaciones requieren tomar decisiones. Estas decisiones normalmente sern resueltas dinmicamen te decidiendo que clases instanciar o sobre que objetos un objeto delegar responsabi lidades. La vala de los patrones de creacin nos dice como estructurar y encapsular estas de cisiones. A menudo hay varios patrones de creacin que puedes aplicar en una situacin. Alguna s veces se pueden combinar mltiples patrones ventajosamente. En otros casos se debe elegir entre los patrones que compiten. Por estas razones es importante conocer los sei s patrones descritos en esta categora. Factory Method [GoF95] Tu escribes una clase para reutilizar con tipos arbitrarios de datos. Tu organiz as esta clase de tal forma que se puedan instanciar otras clases sin depender de ninguna de las c lases que puedan ser instanciadas. La clase reutilizable es capaz de permanecer independie nte de las otras clases instanciadas delegando la eleccin de que clase instanciar a otros ob jetos y referirse a los objetos recin creados a travs de un interface comn. Define una inte rface para crear un objeto, dejando a las subclases decidir el tipo especfico. Permite delegar la responsabilidad de instanciacin a las subclases. Abstract Factory [GoF95] Dado un conjunto de clases abstractas relacionadas, el patrn Abstract Factory per mite el modo de crear instancias de estas clases abstractas desde el correspondiente con junto de subclases concretas. Proporciona una interfaz para crear familias de objetos rel acionados o dependientes sin especificar su clase concreta. El patrn Abstract Factory puede s er muy til para permitir a un programa trabajar con una variedad compleja de entidades exte rnas, tales como diferentes sistemas de ventanas con una funcionalidad similar. Builder [GoF95] Permite a un objeto cliente construir un objeto complejo especificando solamente su tipo y contenido. El cliente es privado de los detalles de construccin del objeto. Separ a la construccin de un objeto complejo de su representacin, para que el mismo proceso d e construccin permita crear varias representaciones.

Prototype [GoF95] Permite a un objeto crear objetos personalizados sin conocer su clase exacta o l os detalles de cmo crearlos. Su tarea es dar objetos prototipo a un objeto que inicializa la cre acin de objetos. El objeto de creacin e inicializacin crea objetos mandando a sus objetos prototipo que hagan una copia de si mismos. Francisco Javier Martnez Juan Pgina 17

Gua de construccin de software en Java con patrones de diseo Singleton [GoF95] Garantiza que solamente se crea una instancia de la clase y provee un punto de a cceso global a l. Todos los objetos que utilizan una instancia de esa clase usan la misma inst ancia. Object Pool [Grand98] Administra la reutilizacin de objetos cuando un tipo de objetos es caro de crear o solamente un nmero limitado de objetos puede ser creado. PATRONES DE PARTICIN En la etapa de anlisis, tu examinas un problema para identificar los actores, cas os de uso, requerimientos y las relaciones que constituyen el problema. Los patrones de est a categora proveen la gua sobre como dividir actores complejos y casos de uso en mltiples cla ses. Layered Initialization [Grand98] Cuando se necesitan mltiples implementaciones de una abstraccin, normalmente se de fine una clase que encapsula la lgica comn y subclases que encapsulan las diferentes lgi cas especializadas. Esto no se puede hacer cuando la lgica comn es utilizada para deci dir que clases especializadas se crean. El patrn Layered Initialization soluciona este pr oblema encapsulando las lgicas comunes y especializadas para crear un objeto en clases n o relacionadas. Filter [BMRSS96] Permite a los objetos que realizan diferentes transformaciones y clculos sobre un conjunto de datos y que tienen interfaces compatibles conectar dinmicamente en el orden en qu e se realizan las operaciones arbitrariamente sobre el conjunto de datos. Composite [GoF95] Permite construir objetos complejos mediante composicin recursiva de objetos simi lares. El patrn Composite tambin permite que los objetos del rbol sean manipulados por un manejador consistente, para requerir todos los objetos hay una superclase o un i nterfaz comn. Permite a los clientes tratar de la misma manera tanto a objetos individual es como a compuestos. PATRONES ESTRUCTURALES

Los patrones de esta categora describen las formas comunes en que diferentes tipo s de objetos pueden ser organizados para trabajar unos con otros. Francisco Javier Martnez Juan Pgina 18

Gua de construccin de software en Java con patrones de diseo Adapter [GoF95] Una clase Adapter implementa un interfaz que conoce a sus clientes y proporciona acceso a una instancia de una clase que no conoce a sus clientes, es decir convierte la i nterfaz de una clase en una interfaz que el cliente espera. Un objeto Adapter proporciona la fu ncionalidad prometida por un interfaz sin tener que conocer que clase es utilizada para impl ementar ese interfaz. Permite trabajar juntas a dos clases con interfaces incompatibles. Iterator [GoF95] Define un interface que declara mtodos para acceder secuencialmente a los objetos de una coleccin. Una clase que accede a una coleccin solamente a travs de un interface independiente de la clase que implementa el interface. Bridge [GoF95] Es til cuando hay una jerarqua de abstracciones y la correspondiente jerarqua de implementaciones. Ms que combinar las abstracciones e implementaciones en muchas clases distintas, el patrn Bridge implementa las abstracciones e implementaciones como c lases independientes que se pueden combinar dinmicamente. Es decir, desacopla una abstr accin de su implementacin y les permite variar independientemente. Facade [GoF95] Simplifica los accesos a un conjunto de objetos relacionados proporcionando un o bjeto que todos los objetos de fuera del conjunto utilizan para comunicarse con el conjunt o. Define una interface de ms alto nivel que permite usar el sistema ms fcil. Flyweight [GoF95] Si instancias de una clase contienen la misma informacin pueden ser utilizadas intercambiablemente, el patrn Flyweight permite a un programa evitar el coste de mltiples instancias que contienen la misma informacin compartiendo una nica instancia. Sopo rta la representacin de un gran nmero de objetos pequeos de una manera eficiente. Dynamic Linkage [Grand98] Permite a un programa solicitar la carga y utilizacin de clases arbitrarias que i mplementan un interface conocido. Virtual Proxy [Larman98] Si un objeto es caro de instanciar y puede que no sea necesario, podra tener vent ajas

posponer la instanciacin hasta que este claro que el objeto se necesita. El patrn Virtual Proxy oculta el hecho de que el objeto todava no existe a sus clientes, teniendo s tos acceso al objeto indirectamente a travs de un objeto proxy que implementa el mismo inter face que el Francisco Javier Martnez Juan Pgina 19

Gua de construccin de software en Java con patrones de diseo objeto que puede no existir. La tcnica de retrasar la instanciacin de un objeto ha sta que este es necesario se llama instanciacin perezosa. Decorator [GoF95] Extiende la funcionalidad de un objeto dinmicamente de tal modo que es transparen te a sus clientes, utilizando una instancia de una subclase de la clase original que dele ga las operaciones al objeto original. Provee una alternativa muy flexible para agregar funcionalid ad a una clase. Cache Management [Grand98] Permite el acceso rpido a objetos que de lo contrario podran llevar un gran tiempo de acceso. Esto implica tener una copia de los objetos que son costosos de construi r. El objeto podra ser costoso de construir por un nmero de razones tales como necesitar un gra n clculo o ser sacado de una base de datos. PATRONES DE COMPORTAMIENTO Los patrones de este tipo son utilizados para organizar, manejar y combinar comp ortamientos. Chain of Responsability [GoF95] Permite a un objeto enviar un comando sin conocer que objeto o objetos lo rn, evitando el acoplamiento entre el que enva y el que recibe una peticin. te el paso del comando a un objeto de la cadena que es parte de una gran estructura. bjeto de la cadena podra manejar el comando, pasar el comando al siguiente objeto de a, o las dos cosas. Command [GoF95] Encapsula una operacin en un objeto, permitiendo parametrizar operaciones, de tal forma que se pueda controlar su seleccin y secuencia, ponerlas en la cola, deshacerlas y manipularlas. Little Language [Grand98] Supn que necesitas resolver muchos problemas similares y te das cuenta de que las soluciones a estos problemas pueden ser expresadas como diferentes combinaciones de un pequeo nmero de elementos o operaciones. El modo ms simple de expresar las solucion es a estos problemas podra ser definir un pequeo lenguaje. Los tipos comunes de probl recibi Esto permi Cada o la caden

emas que se pueden solucionar con un pequeo lenguaje son bsquedas de estructuras de dat os comunes, creacin de complejas estructuras de datos, y asignacin de formato a los d atos. Francisco Javier Martnez Juan Pgina 20

Gua de construccin de software en Java con patrones de diseo Mediator [GoF95] Define un objeto que encapsula la forma en la cual interactan otros. Utiliza un o bjeto para coordinar cambios de estado entre otros objetos. Colocando la lgica en un objeto para manejar cambios de estado de otros objetos, en lugar de distribuir la lgica sobre los otros objetos, dando como resultado una implementacin mas cohesiva de la lgica y decrementando las relaciones entre otros objetos. Promueve el acoplamiento dbil. Snapshot [Grand98] Captura una instantnea del estado de un objeto pudiendo ser restaurado ms tarde. E l objeto que inicializa la captura o restauracin del estado no necesita conocer ninguna in formacin del estado. Slo se necesita conocer cual es el objeto cuyo estado se va a restaurar o capturar implementando un interface particular. Observer [GoF95] Permite a los objetos captar dinmicamente las dependencias entre objetos, de tal forma que un objeto notificar a los objetos dependientes de l cuando cambia su estado, siend o actualizados automticamente. State [GoF95] Encapsula los estados de un objeto como objetos separados, cada pertenencia en u na subclase separada de una clase abstracta estado. Permite a un objeto cambiar su comportamiento cuando su estado interno cambia. El objeto parecer haber cambiado de clase. Null Object [Woolf97] Facilita una alternativa para utilizar null para indicar la ausencia de un objet o al que delegue una operacin. Utilizando null para indicar la ausencia de cada uno de los objetos requeridos se realiza una pregunta para ver si es null antes de cada llamada a los mtodos de otros objetos. En lugar de utilizar null, el patrn Null Object utiliza una referencia a un objeto que no hace nada. Strategy [GoF95] Encapsula algoritmos relacionados en clases que son subclases de una superclase comn. Esto permite la seleccin de un algoritmo que varia segn el objeto y tambin le permi te la variacin en el tiempo.

Template Method [GoF95] Escribe una clase abstracta que contiene parte de la lgica necesaria para realiza r su finalidad. Organiza la clase de tal forma que sus mtodos concretos llaman a un mtodo abstract o Francisco Javier Martnez Juan Pgina 21

Gua de construccin de software en Java con patrones de diseo donde la lgica buscada tendra que aparecer. Facilita la lgica buscada en mtodos de subclases que sobrescriben a los mtodos abstractos. Define un esqueleto de un alg oritmo, delegando algunos pasos a las subclases. Permite redefinir ciertos pedazos del a lgoritmo sin cambiar su estructura. Visitor [GoF95] Un modo de implementar una operacin que involucra a los objetos en una estructura compleja es facilitar la lgica en cada una de sus clases para soportar la operacin . El patrn Visitor facilita un modo alternativo para implementar cada operacin que evita com plicar la estructura de las clases de los objetos colocando toda la lgica necesaria en una clase Visitor separada. El patrn Visitor tambin permite variar la lgica utilizando diferentes cla ses Visitor, es decir, permite definir nuevas operaciones sin cambiar las clases de los objet os sobre las cuales operan. PATRONES DE CONCURRENCIA Los patrones de esta categora permiten coordinar las operaciones concurrentes. Es tos patrones se dirigen principalmente a dos tipos diferentes de problemas: 1. Recursos compartidos: Cuando las operaciones concurrentes acceden a los mismos datos o otros tipos de recursos compartidos, podra darse la posibilidad de que las operaciones interfirieran unas con otras si ellas acceden a los recursos al mismo tiempo. Para garantizar que cada operacin se ejecuta correctamente, la operacin debe ser protegida para acceder a los recursos compartidos en solitario. Sin embargo, si las operaciones estn completamente protegidas, entonces podran bloquearse y no ser capaces de finalizar su ejecucin. El bloqueo es una situacin en la cual una operacin espera por otra para realizar algo antes de que esta proceda. Porque cada operacin esta esperando por la otra para hacer algo, entonces ambas esperan para siempre y nunca hacen nada. 2. Secuencia de operaciones: Si las operaciones son protegidas para acceder a un recurso compartido una cada vez, entonces podra ser necesario garantizar que ellas acceden a los recursos compartidos en un orden particular. Por ejemplo, un objeto nunca ser borrado de una estructura de datos antes de que est sea aadido a la estructura de datos. Single Threaded Execution [Grand98] Algunos mtodos acceden a datos o otos recursos compartidos de tal forma que produ cen resultados incorrectos si hay llamadas concurrentes a un mtodo y ambas llamadas a cceden a los datos o otros recursos compartidos al mismo tiempo. El patrn Single Threaded

Execution Francisco Javier Martnez Juan Pgina 22

Gua de construccin de software en Java con patrones de diseo soluciona este problema impidiendo las llamadas concurrentes a un mtodo que provo can ejecuciones concurrentes del mtodo. Guarded Suspensin [Lea97] Suspende la ejecucin de una llamada a un mtodo hasta que se satisface una precondi cin. Balking [Lea97] Si un mtodo de un objeto es llamado cuando el objeto no esta en un estado apropia do para ejecutar ese mtodo, tiene que retornar del mtodo sin hacer nada. Scheduler [Lea97] Controla el orden en el cual los hilos son organizados para ejecutar el cdigo del hilo nico utilizando un objeto que sigue explcitamente en la sucesin de hilos que esperan. E l patrn Scheduler provee un mecanismo para implementar una poltica de organizacin. Esto es independiente de cada una de las polticas de organizacin especificas. Read/Write Lock [Lea97] Permite accesos concurrentes de lectura a un objeto pero requiere el acceso excl usivo para operaciones de escritura. Producer-Consumer Coordina la produccin y consumo asncrono de informacin o objetos. Two-Phase Termination [Grand98] Facilita el cierre de forma ordenada de un hilo o proceso a travs de la colocacin de un pestillo. El hilo o proceso comprueba el valor del pestillo en puntos estratgicos de su ejecucin. 1.3.6. Patrones de diseo, reglas y creatividad La presencia combinada de todos los elementos de un patrn y cualidades es lo que hace que los patrones sean ms que simples heursticos, reglas o algoritmos. Los heursticos y principios participan frecuentemente en los objetivos y/o razn fundamental de un patrn, pero solamente son elementos de un patrn. Adems de esto como Cope escribe en Software Design Patterns: Common Questions and Answers : Las reglas no son comnmente soportadas por una razn fundamental, no ponen un contexto. Una regla podra ser parte de la solucin en la descripcin de un patrn, pero una regla como solucin no es an suficiente ni necesaria. Los Francisco Javier Martnez Juan Pgina 23

Gua de construccin de software en Java con patrones de diseo patrones no son diseos para ser ejecutados o analizados por ordenadores, como uno podra imaginar cierto para las reglas: los patrones tienen que ser ejecutados por arquitectos con perspicacia, sabidura, experiencia, y un sentido de la esttica. Un patrn es el proceso que genera una solucin, pero podra generar un inmenso nmero d e soluciones variantes (imaginablemente sin repetir la misma solucin dos veces). El elemento humano de los patrones es que principalmente contribuye a su variabilidad y adap tabilidad, y normalmente necesita un gran grado de creatividad en sus aplicaciones y combinac iones. As que, como el proceso de arquitectura y diseo son propsitos creativos, as tambin es l a aplicacin de patrones. En el mismo libro mencionado anteriormente, Cope dice: Si el diseo es codificado en patrones, la creatividad necesaria ser grande? Podemos reemplazar nosotros los caros diseos con los programadores menos sofisticados que se guan por patrones? La respuesta es que la creatividad es todava necesaria para dar forma a los patrones en un contexto dado. Tambin como los modistas ajustan a la medida un patrn a un cliente individual, y quizs algn suceso especfico cuando el vestido esta puesto, as los diseadores deben ser creativos cuando utilizan patrones. Los patrones canalizan la creatividad; no la reemplazan ni la reducen. 1.3.7. Patrones y algoritmos La seccin titulada patrones de diseo, reglas y creatividad tambin se aplica en gran parte a los algoritmos y sus estructuras de datos. Ciertamente, los algoritmos y estruct uras de datos pueden ser empleados en la implementacin de uno o varios patrones, pero los algor itmos y las estructuras de datos generalmente solucionan problemas computacionales ms con cretos como ordenacin y bsqueda. Los patrones son tpicamente interesantes en arquitecturas de gran extensin, que tienen efectos de gran escala. Los patrones de diseo solucionan a la gente y desarrolladores cuestiones como mantenibilidad, reusabilidad, comunicabi lidad y encapsulacin. Los algoritmos y estructuras de datos son normalmente relacionados casi exclusiv amente con el contexto de optimizacin o tiempo, o algunos otros aspectos de la computacin com pleja y recursos en uso. Tratan de encontrar la ms compacta y eficiente solucin que realiz a alguna computacin importante o almacenar y recordar sus resultados. Hay un gran nmero de libros de algoritmos y estructuras de datos que proporcionan el cdigo fuente y anlisis para estructuras como los rboles AVL o los rboles desplegados . Pero en muchos de estos mismos libros hay una pequea mencin de cmo implementar esta s

estructuras de un modo que proporcione mantenibilidad, adaptabilidad y reutiliza cin. Mirando el tiempo computacional no soluciona el conjunto de efectos que afectan a las arquitecturas e implementaciones tan bien como los usuarios. Francisco Javier Martnez Juan Pgina 24

Gua de construccin de software en Java con patrones de diseo Esto es porque los algoritmos y estructuras de datos tienden a ser ms concretos q ue los patrones: porque ellos solucionan mayormente cuestiones de complejidad computaci onal, y no tanto las cuestiones subyacentes de la gente que utiliza y construye software. L os patrones fundamentalmente solucionan cuestiones ms complejas que las simples cuestiones de eficiencia/memoria hardware y software. Por supuesto los desarrolladores de software necesitan conocer ambos y encontrar las arquitecturas apropiadas y con las soluciones apropiadas para los problemas computacionales. As sern tan necesarios los patrones como los algoritmos y las est ructuras de datos (y su uso conjunto). 1.3.8. Patrones y frameworks Relacionados con los patrones de diseo estn los frameworks. Un framework es una mi ni arquitectura que proporciona la estructura genrica y el comportamiento para una f amilia de abstracciones a lo largo de un contexto de metforas que especifican su colaboracin y es utilizado en un dominio dado. El framework codifica el contexto en una clase de mquina virtual mientras hace la s abstracciones abiertas. Un framework no es generalmente una aplicacin completa si no que a menudo le falta la funcionalidad de una aplicacin especfica. Una aplicacin, en camb io puede ser construida con uno o ms frameworks insertando dicha funcionalidad. Una posible definicin de framework es: conjunto de clases cooperantes que hace reusable un di seo para una clase especfica de software. Un framework proporciona una gua arquitectnic a para dividir el diseo en clases y definir sus responsabilidades y colaboraciones. Un framework dicta la arquitectura de la aplicacin. Define el conjunto de la estruct ura, su particin en clases y objetos, la colaboracin entre ellos y el hilo de control. La diferencia entre un framework y una librera ordinaria de programacin es que el framework utiliza un flujo de control invertido con respecto a los clientes. Los frameworks pueden incluir patrones de diseo. Sin embargo hay que distinguirlo s los frameworks son ejecutables mientras que los patrones de diseo representan un cono cimiento o experiencia sobre software. En realidad, un framework se puede ver como la implementacin de un sistema de patrones de diseo. Los frameworks son de naturaleza fsica, mientras que los patrones son de naturaleza lgica: los frameworks son la re alizacin

fsica de uno o varios patrones de soluciones software; los patrones son las instr ucciones de cmo implementar estas soluciones. Las principales diferencias entre patrones de diseo y frameworks son: 1. Los patrones de diseo son ms abstractos que los frameworks. Los frameworks pueden ser codificados, pero solo los ejemplos de patrones de diseo pueden ser codificados. Un caracterstica de los frameworks es que pueden ser escritos bajo lenguajes de programacin y no solamente estudiados para ejecutarse y Francisco Javier Martnez Juan Pgina 25

Gua de construccin de software en Java con patrones de diseo reutilizarse directamente. En cambio, los patrones de diseo tienen que ser implementados cada vez que son usados. Los patrones de diseo tambin explican el objetivo, los cambios y las consecuencias de un diseo. 2. Los patrones de diseo son elementos arquitectnicos ms pequeos que los frameworks. Un framework contiene varios patrones de diseo, lo contrario nunca es cierto. 3. Los patrones de diseo estn menos especializados que los frameworks. Los frameworks siempre tienen un dominio particular de aplicacin. En cambio, los patrones de diseo pueden ser utilizados en cualquier tipo de aplicacin. 1.3.9. Donde usar los patrones Vamos a ver algunos casos en los que los patrones de diseo se muestran como una s olucin efectiva para resolver problemas de diseo: ENCONTRAR LOS OBJETOS APROPIADOS La parte difcil del diseo orientado a objetos es descomponer un sistema en objetos. La tarea es difcil porque muchos factores entran en juego: encapsulacin, granularidad, dependencia, flexibilidad, realizacin, evolucin, reusabilidad. Todos ellos influyen en la descomposicin, a menudo de forma conflictiva. Las metodologas de diseo orientadas a objetos tienen diferentes aproximaciones. Puedes escribir la declaracin de un problema, simplemente sacando los nombres y los verbos, y creando las correspondientes clases y operaciones. O puedes enfocarlo sobre las colaboraciones y responsabilidades del sistema. O puedes modelar el mundo real y transladar los objetos encontrados durante el anlisis al diseo. Siempre habr desacuerdos sobre que aproximacin es la mejor. Muchos objetos en un diseo vienen del modelo de anlisis. Pero los diseos orientados a objetos a menudo terminan en clases que no tienen homlogos en el mundo real. Algunos de estos son clases de bajo nivel como los arrays. Otros son de nivel ms alto. Por ejemplo el patrn Composite introducen una abstraccin para tratar uniformemente los objetos que no tienen un homlogo fsico. El modelado estricto del mundo real nos gua a un sistema que refleja las realidades de hoy pero no necesariamente las de maana. Las abstracciones que emergen durante el diseo son la clave para hacer un diseo flexible. Los patrones de diseo te ayudan a identificar las abstracciones menos obvias y los objetos que pueden capturarlas. Por ejemplo, los objetos que representan un algoritmo no ocurren en la naturaleza, aunque son una parte crucial de los diseos flexibles. El patrn Strategy describe como implementar una familia de algoritmos intercambiables. El patrn State representa cada estado de una entidad como un objeto. Estos objetos son raramente encontrados durante el anlisis e incluso en las primeras etapas del diseo; sino que son descubiertas ms tarde en el transcurso de realizar un diseo ms flexible y reutilizable. Francisco Javier Martnez Juan Pgina 26

Gua de construccin de software en Java con patrones de diseo DETERMINAR EL NMERO Y TAMAO DE LOS OBJETOS Los objetos pueden variar enormemente en tamao y nmero. Cmo decidimos como debera ser un objeto?. Los patrones de diseo tambin solucionan est cuestin. El patrn Facade describe como representar subsistemas completos como objetos, y el patrn Flyweight como soportar un enorme nmero de objetos de pequeo tamao. Otros patrones de diseo describen formas de descomponer un objeto en objetos ms pequeos. El Abstract Factory y el Builder proporcionan objetos cuyas nicas responsabilidades son crear otros objetos. El Visitor y el Command proporcionan objetos cuyas nicas responsabilidades son las de implementar una peticin sobre otro objeto o grupo de objetos. ESPECIFICAR LAS INTERFACES DE LOS OBJETOS Cada operacin declarada en un objeto especfica el nombre de la operacin, los objetos que tiene como parmetros, y el valor que retorna la operacin. Esto se conoce como la signatura de la operacin. El conjunto de todas las signaturas definidas en un objeto se llama interface del objeto. Un interface de un objeto caracteriza el conjunto completo de peticiones que pueden ser enviadas al objeto . Un tipo es un nombre utilizado para denotar un interface particular. Los interfaces son fundamentales en los sistemas orientados a objetos. Los objetos solamente se conocen a travs de sus interfaces. No hay forma de conocer nada acerca de un objeto o preguntarle nada sin ser a travs de su interface. Un interface de un objeto no dice nada sobre su implementacin, diferentes objetos tienen libertad para implementar las peticiones de forma diferente. Esto significa que dos objetos que tienen implementaciones completamente diferentes pueden tener interfaces idnticos. Los patrones de diseo te ayudan a definir interfaces para identificar sus elementos claves y los tipos de datos que consiguen enviar a travs de un interface. Un patrn de diseo tambin puede decirnos que no poner en el interface. Los patrones de diseo tambin especifican relaciones entre interfaces. En particular, ellos a menudo requieren algunas clases que tengan interfaces simila res, o meter restricciones sobre los interfaces de algunas clases. Por ejemplo, el Decorator y el Proxy requieren que los interfaces de objetos Decorator y Proxy sean idnticos para los objetos Decorados y Proxies. En el Visitor, el interface Visitor debe reflejar todas las clases de objetos que los visitor pueden visitar . ESPECIFICAR LA IMPLEMENTACIN DE LOS OBJETOS 1. Herencia de clases frente a herencia de interfaces: Muchos patrones de diseo dependen de esta distincin. Por ejemplo, los objetos en el patrn Chain of Responsability tienen que tener un interface comn, pero normalmente no comparten una implementacin comn. En el patrn Composite, el componente define un interface comn, pero el compuesto a menudo define una implementacin comn. Los patrones Command, State, y Strategy son a menudo implementados con clases abstractas que son interfaces puros. 2. La programacin hacia un interface, no una implementacin: Cuando la herencia es utilizada cuidadosamente, todas las clases derivan

Francisco Javier Martnez Juan Pgina 27

Gua de construccin de software en Java con patrones de diseo de una clase abstracta compartiendo su interface. Esto implica que una subclase slo aade o sobrescribe operaciones y no esconde operaciones de la clase padre. Todas las subclases pueden luego responder a las peticiones del interface de esta clase abstracta, siendo todas ellas subtipos de la clase abstracta. La manipulacin de objetos solamente en trminos del interface definido por clases abstractas tiene dos beneficios: Los clientes permanecen sin enterarse de los tipos especficos de objetos que usan, los objetos son adheridos al interface que los clientes esperan. Los clientes permanecen sin enterarse de las clases que implementan esos objetos. Los clientes solamente conocen las clases abstractas definidas en el interface. La reduccin de las dependencias de implementacin entre subsistemas nos conduce al siguiente principio del diseo orientado a objetos reutilizable: Programar un interface, no una implementacin. No declarar variables que sean instancias de una clase particular. En cambio consigna solamente un interface definido por una clase abstracta. Esto es un tema comn en los patrones de diseo. Si tienes que instanciar clases concretas (esto es, especificar una implementacin particular) en alguna parte de tu sistema, los patrones de creacin (Abstract Factory, Builder, Factory Method, Prototype, y Singleton) te permiten hacerlo. Para abstraer el proceso de creacin del objeto, estos patrones te dan diferentes caminos para asociar un interface con su implementacin transparentemente a la instanciacin. Los patrones de creacin aseguran que tu sistema esta escrito en trminos de interfaces, no de implementaciones. HACER FUNCIONAR LOS MECANISMOS DE REUTILIZACIN Mucha gente puede comprender conceptos como objetos, interfaces, clases, y herencia. El desafo consiste en aplicarlos para construir software flexible y reutilizable, y los patrones de diseo pueden ensearte como hacerlo. 1. Herencia frente a composicin: Reuso de caja blanca o caja negra: Las dos tcnicas ms comunes para reutilizar funcionalidades en un sistema orientado a objetos son la herencia de clases y la composicin de objetos. La herencia de clases nos permite definir la implementacin de una clase en trminos de otra. La reutilizacin mediante subclases suele ser referida como reutilizar la caja blanca. El trmino caja blanca se refiere a la visibilidad: con la herencia el interaar de la clase padre es a menudo visible para las subclases. La composicin de objetos es una alternativa a la herencia de clases. Aqu las nuevas funcionalidades son obtenidas ensamblando o componiendo objetos para conseguir funcionalidades ms complejas. La composicin de objetos requiere que los objetos sean compuestos teniendo interfaces bien definidos. Este estilo de reutilizacin se llama reutilizar la caja negra, Francisco Javier Martnez Juan Pgina 28

Gua de construccin de software en Java con patrones de diseo porque los detalles internos de los objetos no son visibles. Los objetos parecen solamente cajas negras . La herencia y la composicin tienen cada una sus ventajas y sus desventajas. La herencia de clases se define estticamente en tiempo de compilacin y es fcil de utilizar. La composicin de objetos se define dinmicamente en tiempo de ejecucin a travs de objetos que adquieren referencias a otros objetos. La composicin de objetos tiene otro efecto sobre el diseo de un sistema. Favorecer la composicin sobre la herencia de clases nos ayuda a conservar la encapsulacin de cada clase. La jerarqua de clases permanecer pequea y ser menos probable que se formen estructuras inmanejables. Por otro lado, un diseo basado en la composicin de objetos tendr ms objetos, y el comportamiento del sistema depender de sus interrelaciones en lugar de estar definido en una clase. Esto nos gua hacia el segundo principio del diseo orientado a objetos: Favorecer la composicin de objetos sobre la herencia de clases. Idealmente, no se debera tener que crear nuevos componentes para realizar la reutilizacin. Debera ser posible conseguir todas las funcionalidades necesarias slo por ensamblamiento de componentes existentes a travs de la composicin de objetos. Pero esto raramente ocurre, porque el conjunto de componentes disponibles nunca es lo suficientemente rico en la prctica. Reutilizar mediante la herencia hace ms fcil crear nuevos componentes que pueden ser compuestos con otros. Por consiguiente, la herencia y la composicin trabajan juntas. No obstante, la experiencia dice que los diseadores emplean demasiado la herencia como una tcnica de reutilizacin, y los diseos, algunas veces, son ms reutilizables y ms simples utilizando ms la composicin de objetos. La composicin de objetos es aplicada una y otra vez en los patrones de diseo. 2. Delegacin: La delegacin es un modo de hacer composicin tan poderoso para la reutilizacin como la herencia. En la delegacin dos objetos estn involucrados en el manejo de una peticin: un objeto receptor delega operaciones a su delegado. Esto indica que una clase mantiene una referencia a una instancia de otra clase. La principal ventaja de la delegacin es que hace ms fcil componer comportamientos en tiempo de ejecucin y cambiar la forma en que ellos estn compuestos. Varios patrones de diseo utilizan delegacin. Los patrones State, Strategy, y Visitor dependen de esto. En el patrn State , un objeto delega la peticin a un objeto estado que representa su estado actual. En el patrn Strategy, un objeto delega una peticin especfica a un objeto que representa la estrategia para llevar a cabo esa peticin. Un objeto solamente tendr un estado, pero est puede tener muchas estrategias para peticiones diferentes. El propsito de ambos patrones es cambiar el comportamiento de un objeto cambiando los objetos sobre los cuales delegar la peticin. En el patrn Visitor, la operacin que consigue Francisco Javier Martnez Juan Pgina 29

Gua de construccin de software en Java con patrones de diseo realizarse sobre cada elemento de una estructura de objetos es siempre delegada al objeto Visitor. Otros patrones utilizan la delegacin no tan fuertemente. El patrn Mediator introduce un objeto para mediar la comunicacin entre otros objetos. Algunas veces el objeto Mediador implementa operaciones simplemente para enviarlas o otros objetos; otras veces pasa una referencia a l mismo y por consiguiente utiliza la verdadera delegacin. El patrn Chain of Responsability maneja peticiones para enviarlas desde un objeto a otros a travs de una cadena de objetos. Algunas veces esta peticin lleva consigo una referencia al objeto original que recibi la peticin, en cuyo caso el patrn utiliza delegacin. El patrn Bridge desacopla una abstraccin de su implementacin. Si la abstraccin y una implementacin particular estn estrechamente relacionadas, luego la abstraccin podra delegar operaciones a esa implementacin. La delegacin es un ejemplo extremo de la composicin de objetos. Esto permite que se pueda sustituir siempre la herencia con la composicin de objetos como mecanismo para reutilizar cdigo. 3. Herencia frente a clases genricas: Las clases genricas es otra tcnica para reutilizar funcionalidades. Est tcnica nos permite definir un tipo sin especificar los otros tipos que utiliza. Los tipos no especificados son suministrados como parmetros en el punto de uso. Por ejemplo, una lista puede ser parametrizada por el tipo de elementos que contiene. Las clases genricas nos proporcionan una tercera forma (en adicin a la herencia de clases y a la composicin de objetos) para componer comportamientos en sistemas orientados a objetos. Muchos diseos pueden ser implementados utilizando alguna de estas tres tcnicas. RELACIONAR LAS ESTRUCTURAS QUE VA A HABER EN TIEMPO DE COMPILACIN Y EN TIEMPO DE EJECUCIN La estructura de un programa orientado a objetos en tiempo de ejecucin normalmente tiene poco parecido con su estructura del cdigo. La estructura del cdigo se termina en el tiempo de compilacin y son clases en relaciones de herencia fijas. El tiempo de ejecucin de un programa consiste en cambios rpidos de la comunicacin entre objetos. En realidad las dos estructuras son ampliamente independientes. Con tanta disparidad entre las estructuras en tiempo de ejecucin y en tiempo de compilacin esta claro que el cdigo no revelar nada sobre cmo trabajar un sistema. Las estructuras en tiempo de ejecucin del sistema deben ser impuestas por el diseador ms que por el lenguaje. Las relaciones entre los objetos y sus tipos deben ser diseadas con mucho cuidado, porque determinan como de buena o mala es la estructura en tiempo de ejecucin. Muchos patrones de diseo capturan explcitamente la distincin entre estructuras en tiempo de compilacin y en tiempo de ejecucin. Los patrones Composite y Decorator son especialmente tiles para construir estructuras complejas en tiempo de ejecucin. El patrn Observer se involucra en estructuras en tiempo de ejecucin que son difciles de comprender a menos que se conozca el patrn. El Francisco Javier Martnez Juan Pgina 30

Gua de construccin de software en Java con patrones de diseo patrn Chain of Responsability tambin resulta en la comunicacin de patrones que la herencia no revela. En general, las estructuras en tiempo de ejecucin no son claras desde el cdigo hasta que no se comprenden los patrones. RAZONES DE CAMBIO Cada patrn de diseo permite que algunos aspectos de la estructura del sistema varen independientemente de otros aspectos, haciendo por tanto sistemas ms robustos para un tipo particular de cambio. Alternativas eficientes para volver a disear la aplicacin en los siguientes casos: 1. Crear un objeto mediante la especificacin de una clase: especificando un nombre de clase cuando se crea un objeto hace que te lleve a una implementacin particular en vez de a una interfaz. Este compromiso puede complicar futuros cambios. Para evitarlo, crea los objetos indirectamente. Patrones de diseo: Abstract Factory, Factory Method, Prototype. 2. Dependencia de operaciones especficas: al especificar una operacin te compromete a una nica forma de satisfacer la peticin que no se puede cambiar. Para evitarlo, peticiones fuertemente codificadas, se realiza tan fcil como cambiar la forma en que se satisface una peticin tanto en tiempo de compilacin como en tiempo de ejecucin. Patrones de diseo: Chain of Responsibility, Command. 3. Dependencia de la plataforma hardware y/o software: el software dependiente de un hardware concreto es difcil de portar a otras plataformas. Incluso podra ser difcil de mantenerlo en su plataforma original. Por eso es importante que el diseo del sistema lmite sus dependencias con la plataforma. Patrones de diseo: Abstract Factory, Bridge. 4. Dependencia de la implementacin o representacin de un objeto: los clientes que conocen la representacin interna de un objeto pueden necesitar cambios si se modifica la representacin interna de dicho objeto. Patrones de diseo: Abstract Factoy, Bridge, Proxy. 5. Dependencias de algoritmos: los algoritmos son a optimizados y reemplazados durante el desarrollo objetos que dependen de un algoritmo tendrn que cuando el algoritmo cambie. Patrones de diseo: Builder, Iterator, Strategy, Visitor. menudo extendidos, y la reutilizacin. Los ser modificados Template Method,

6. Gran acoplamiento entre clases: al cambiar o eliminar una clase se deben cambiar muchas clases relacionadas, por lo que el sistema es difcil de entender, de mantener y de portar a otra plataforma. La prdida de

acoplamiento incrementa la probabilidad de que una clase pueda ser reutilizada por s misma y que un sistema sea mas entendible, portable, modificable y extensible. Los patrones de diseo utilizan tcnicas tales como el acoplamiento abstracto para promover la prdida de acoplamiento en los sistemas. Francisco Javier Martnez Juan Pgina 31

Gua de construccin de software en Java con patrones de diseo Patrones de diseo: Abstract Factory, Bridge, Chain of Responsibility, Command, Facade, Mediator, Observer. 7. Extensin de la funcionalidad mediante herencia: para definir una subclase se necesita un conocimiento de la clase padre con lo que se puede romper la encapsulacin. La composicin de objetos en general y la delegacin en particular proveen alternativas flexibles a la herencia para combinar comportamientos. Pueden aadirse nuevas funcionalidades a una aplicacin mediante la composicin de objetos existentes mejor que definiendo nuevas subclases de clases existentes. Por otro lado, la gran utilizacin de la composicin de objetos puede dar diseos ms difciles de entender. Muchos patrones de diseo producen diseos en los cuales se puede introducir una nueva funcionalidad definiendo solamente una subclase y componiendo sus instancias con algunas existentes. Patrones de diseo: Bridge, Chain of Responsibility, Composite, Decorator, Observer, Strategy. 8. Imposibilidad de alterar las clases de forma conveniente: a veces hay que modificar clases que no se pueden modificar convenientemente. Quizs necesitas el cdigo fuente y no lo tienes (como puede ser el caso de una librera comercial). O a lo mejor algn cambio podra requerir la modificacin de muchas subclases existentes. Los patrones de diseo ofrecen formas para modificar clases en estas circunstancias. Patrones de diseo: Adapter, Decorator, Visitor. 1.3.10. Seleccionar un patrn de diseo De entre los diferentes patrones de diseo que existen puede ser complicado la ele ccin de uno para el diseo de una aplicacin. Entre las pautas que hay que seguir a la hora de seleccionar un patrn se pueden indicar las siguientes: 1. Observar como el patrn de diseo resuelve los problemas de diseo (explicado en el apartado anterior, apartado 1.3.9). 2. Revisar las secciones de Objetivo (apartado 1.3.5). Puedes utilizar la clasificacin mostrada en forma de tabla en el apartado 1.3.4 para facilitar la bsqueda. 3. Estudiar la interrelacin entre los diferentes patrones. Estudiar estas relaciones puede guiarte directamente al patrn correcto o grupo de patrones. 4. Estudiar los patrones con un propsito similar. Hay patrones que son muy parecidos estudiar sus similitudes y sus diferencias te ayudar en la eleccin del p atrn que mejor se adapte a tu problema. 5. Examinar las razones de cambio. Mirar las causas de rediseo que estn en el apartado 1.3.9 para ver si tu problema esta involucrado en una o ms de una. Luego mirar los patrones que te ayudan a evitar las causas de rediseo. 6. Considerar lo que se debera cambiar en el diseo concreto. Este apartado es el

opuesto al anterior, es decir al enfocado sobre las razones de cambio. En lugar de considerar que podra forzar un cambio en un diseo, considera lo que quieres que Francisco Javier Martnez Juan Pgina 32

Gua de construccin de software en Java con patrones de diseo sea capaz de cambiar sin redisearlo. El objetivo aqu es encapsular el concepto que vara, un fin de muchos patrones de diseo. Son aspectos del diseo que los patrones de diseo permiten que varen independientemente, por lo tanto puedes hacer cambios sin redisear. 1.3.11. Como usar un patrn de diseo Una vez seleccionado el patrn de diseo que se va a aplicar hay que tener en cuenta las siguientes claves para utilizar el patrn: Leer el patrn de diseo por encima. Prestar una atencin particular a las secciones Aplicabilidad y Consecuencias para asegurarse de que el patrn es correcto para tu problema. Observar la estructura, los elementos que participan en el patrn y las colaboraciones entre ellos. Asegurarse de que comprendes las clases y objetos del patrn y como se relacionan. Mirar la seccin Cdigo del ejemplo para ver un ejemplo concreto del patrn en cdigo. Estudiar el cdigo te ensear como implementar el patrn. Escoger nombres significativos de los elementos que participan en el patrn para el contexto de la aplicacin. Los nombres de los elementos de un patrn son normalmente demasiado abstractos para aparecer directamente en una aplicacin. No obstante, es muy til incorporar los nombres de los participantes en el nombre que aparece en la aplicacin. Esto te ayudar a tener el patrn ms explcito en la implementacin. Definir las clases. Declarar sus interfaces, establecer sus relaciones de herenc ia, y definir las variables instanciadas que representan datos y referencias de obje tos. Identificar las clases existentes en tu aplicacin que el patrn afectar y modificar adecuadamente. Definir nombres especficos para las operaciones en dicha aplicacin. Otra vez, los nombres dependen generalmente de la aplicacin. Utilizar las responsabilidades y colaboraciones asociadas con cada operacin como gua.

Implementar las operaciones que conllevan responsabilidad y colaboracin en el patrn. La seccin Implementacin te ofrece una gua en la implementacin. Los ejemplos de la seccin Cdigo del ejemplo tambin te ayudan. Estas son slo unas directrices para empezar. Luego desarrollars tu propia forma de trabajar con patrones de diseo. Antes de terminar este apartado sobre como usar patrones de diseo, habra que decir algo sobre como no usar los patrones de diseo. Los patrones de diseo no se deben de apl icar indiscriminadamente. A menudo consiguen flexibilidad y variabilidad introduciend o niveles adicionales de tortuosidad, y pueden complicar un diseo y/o mayores costes de rea

lizacin. Un patrn de diseo solamente debera ser aplicado cuando la flexibilidad que permite es Francisco Javier Martnez Juan Pgina 33

Gua de construccin de software en Java con patrones de diseo necesaria. La seccin Consecuencias obligaciones de un patrn. es de mucha ayuda para evaluar los beneficios y

1.3.12. El futuro de los patrones La gran popularidad que han ido adquiriendo los patrones hacen que la comunidad software los utilice y los soporte comnmente. Existen tres grupos de personas que usan pat rones para documentar sus procesos de desarrollo de software en la forma de un lenguaje de patrones. Varias notaciones usadas por las Tecnologas Orientadas a Objetos han aadido soport e para el modelado y representacin de patrones de diseo. Muchas herramientas de desarroll o de software han aadido un soporte similar. Algunos proyectos de investigacin estn inte ntando codificar patrones de diseo con el propsito de generar cdigo fuente. Algunas librera s comerciales de software proporcionan implementacin de algunos patrones de diseo (J ava utiliza unos pocos en sus libreras estndar). Se piensa que en poco tiempo los leng uajes de programacin introducirn sintaxis para representar patrones como unidades de constr uccin de software. Hay una especulacin a cerca de s los patrones sustituirn algn da a los programadores. Esta misma especulacin ya ha aparecido en algunas ocasiones con la introduccin de nuevas tecnologas. Los lenguajes y las herramientas que se usan para solucionar problema s software evolucionarn, pero se seguir necesitando desarrolladores con la misma evolucin. Aunque la habilidad de codificar patrones como componentes de software pueda lle gar a ser importante, ms importante ser el conocimiento de cmo y cuando aplicar y combinar patrones, en conjuncin con la habilidad de usar un vocabulario de nombres de patr ones para comunicarse con otros desarrolladores. 1.4. ANTIPATRONES Como en la mayor parte de las disciplinas tambin existen malos usos que estn ms o m enos extendidos, y que por lo tanto no aportan soluciones efectivas a la resolucin de problemas. Si un patrn es una buena prctica, entonces un antipatrn es una mala prctica. Hay dos nociones de antipatrones: 1. Aquellos que describen una mala solucin a un problema que da como resultado una mala situacin. 2. Aquellos que describen como salir de una mala situacin y convertirla en una buena solucin.

Los antipatrones deben ser valorados porque a menudo es tan importante ver y ent ender malas soluciones como ver y entender las buenas. Francisco Javier Martnez Juan Pgina 34

Gua de construccin de software en Java con patrones de diseo Brown, Malveau, MacCormick y Mowbray han escrito un libro sobre los antipatrones que intenta identificar y diagnosticar varias anti-soluciones para corregirlas y pre venirlas. Los antipatrones ms tiles sern aquellos que permiten rehacer un buen diseo a partir de u no malo. Se puede definir entonces un patrn de la siguiente forma: Forma literaria que describe una solucin comnmente dada a un problema que genera consecuencias negativas decididamente . Estos antipatrones se pueden encontrar en muchas disciplinas. Atenindonos a la in geniera del software se pueden clasificar los diferentes tipos de antipatrones de la siguien te forma: Antipatrones de desarrollo de software: 1. The Blob ( clases gigantes ). 2. Lava Flow ( cdigo muerto ). 3. Funcional Decomposition ( diseo no orientado a objetos ). 4. Poltergeists ( no se sabe bien lo que hacen algunas clases ). 5. Golden hammer ( para un martillo todo son clavos ). 6. Spaghetti code ( muchos if o switch ). 7. Cut-and-paste programming ( cortar y pegar cdigo ). Antipatrones de arquitectura de software: 1. Stovepipe enterprise ( aislamiento en la empresa ). 2. Stovepipe system ( aislamiento entre sistemas ). 3. Vendor Lock-In ( arquitectura dependiente de producto ). 4. Arquitecture by implication. 5. Design by committee ( navaja suiza ). 6. Reinvent the Wheel ( reinventar la rueda ). Antipatrones de gestin de proyectos software: 1. Analysis paralysis. 2. Death by planning. 3. Corncob ( personas problemticas ). 4. Irrational management. 5. Project mismanegement. De todos estos patrones los ms relacionados con los patrones de diseo son los de desarrollo de software por lo que habr que evitarlos en la medida de lo posible. Todos los antipatrones tienen al lado una aclaracin que permite intuir a lo que se refieren . Francisco Javier Martnez Juan Pgina 35

Gua de construccin de software en Java con patrones de diseo 1.5. CONCLUSIN Todas las disciplinas de la ingeniera desarrolladas tienen un compendio colectivo de observacin, experimentacin de buenas prcticas y lecciones aprendidas para resolver conocidos problemas de ingeniera. Los grandes ingenieros no solo disean sus produc tos de acuerdo estrictamente a los principios de la matemtica y la ciencia. Ellos deben adaptar sus soluciones para realizar los cambios y compromisos ptimos entre las soluciones co nocidas, los principios, y las restricciones que encuentran los incrementos y cambios dem andados de coste, tiempo, calidad y necesidades de los clientes. Los patrones nos ayudan a conseguir la formacin para identificar que es constante y reconocer los cambios incesantes. En este sentido, los patrones realizan la convergencia de las interacciones dinmicas de c omponentes en configuraciones estables, que se solucionan a travs de sistemas exitosos. Los patrones representan la experiencia, la cual, a travs de su asimilacin, impart e la perspicacia y el conocimiento de los diseadores expertos. Los patrones ayudan a a moldar la visin compartida de la arquitectura, y coleccin de estilos. Si queremos disear soft ware que se desenvuelve en una disciplina de ingeniera desarrollada, entonces est provee la s mejores prcticas y lecciones aprendidas que deben ser suficientemente y formalmente documentadas, compiladas, escrutadas y ampliamente difundidas como patrones (y antipatrones). Una vez que una solucin ha sido expresada en forma de patrn, est pod ra ser aplicada y reaplicada a otros contextos, y facilitar ampliamente la reutiliz acin a travs de todos los utensilios del espectro de la ingeniera de software tales como: anlisis, arquitecturas, diseos, implementaciones, algoritmos y estructuras de datos, tests, planes y orga nizacin de estructuras. Los patrones son herramientas vlidas para capturar y comunicar los conocimientos y experiencia adquiridos para proporcionar calidad y productividad software, para solucionar las cuestiones fundamentales en el desarrollo de software. Al utilizar estas her ramientas estamos mejor adaptados a solucionar retos como comunicacin del conocimiento de arquitecturas entre diseadores; acomodando un nuevo paradigma de diseo o estilo arquitectnico; resolviendo objetivos no funcionales tales como la reutilizacin, po rtabilidad, y extensibilidad; y evitando errores y dificultades del diseo, que ha sido aprendid o tradicionalmente solamente a travs de las experiencia . Los patrones exponen conocimiento sobre la construccin de software que ha sido fr uto de muchos expertos durante muchos aos. Todo trabajo sobre patrones debera concentrars

e en aplicarse ampliamente estos valiosos recursos. Todo diseador de software debera ser capaz de utilizar patrones correctamente cuando construye sistemas software. Una vez archivados, seremos capaces de ver la inteligencia humana que reflejan los patro nes, cada patrn por individual y todos los patrones en su conjunto. Francisco Javier Martnez Juan Pgina 36

Gua de construccin de software en Java con patrones de diseo 2. EXPLICACIN DETALLADA DE LOS PATRONES DE DISEO UTILIZADOS EN LOS EJEMPLOS 2.1. SINGLETON [GoF95] 2.1.1. Objetivo Garantiza que solamente se crea una instancia de la clase y provee un punto de a cceso global a l. Todos los objetos que utilizan una instancia de esa clase usan la misma inst ancia. 2.1.2. Aplicabilidad El patrn Singleton se puede utilizar en los siguientes casos: Debe haber exactamente una instancia de la clase. La nica instancia de la clase debe ser accesible para todos los clientes de esa c lase. 2.1.3. Solucin El patrn Singleton es relativamente simple, ya que slo involucra una clase. Una clase Singleton tiene una variable static que se refiere a la nica instancia de la clase que quieres usar. Esta instancia es creada cuando la clase es cargada en memoria. T d eberas de implementar la clase de tal forma que se prevenga que otras clases puedan crear instancias adicionales de una clase Singleton. Esto significa que debes asegurarte de que t odos los constructores de la clase son privados. Para acceder a la nica instancia de una clase Singleton, la clase proporciona un mtodo static, normalmente llamado getInstancia, el cual retorna una referencia a la nic a instancia de la clase. Francisco Javier Martnez Juan Pgina 37

Gua de construccin de software en Java con patrones de diseo Singleton static instanciaSingleton : Singleton Singleton() static getInstancia() Clase Singleton. 2.1.4. Consecuencias Existe exactamente una instancia de una clase Singleton. Otras clases que quieran una referencia a la nica instancia de la clase Singleton conseguirn esa instancia llamando al mtodo static getInstancia de la clase. Contro la el acceso a la nica instancia. Tener subclases de una clase Singleton es complicado y resultan clases imperfectamente encapsuladas. Para hacer subclases de una clase Singleton, debera s tener un constructor que no sea privado. Tambin, si quieres definir una subclase de una clase Singleton que sea tambin Singleton, querrs que la subclase sobrescriba e l mtodo getInstancia de la clase Singleton. Esto no ser posible, ya que mtodos como getInstancia deben ser static. Java no permite sobrescribir los mtodos stati c. 2.1.5. Implementacin Para forzar el carcter de una clase Singleton, debes codificar la clase de tal fo rma que prevengas que otras clases creen directamente instancias de la clase. El modo de realizarlo es declarar todos los constructores de la clase privados. Tener cuidado de declarar al menos un constructor privado. Si una clase no declara ningn constructor, entonces un const ructor pblico es automticamente generado por ella. Una variacin comn del patrn Singleton ocurre en situaciones donde la instancia de u n Singleton podra no ser necesaria. En estas situaciones, puedes posponer la creacin de la instancia hasta la primera llamada a getInstancia. Otra variacin sobre el patrn Singleton desciende del hecho de que la poltica de instanciacin de una clase est encapsulada en el mtodo de la clase getInstancia. Deb ido a esto, es posible variar la poltica de creacin. Una posible poltica es tener el mtodo getInstancia que retorne alternativamente una de las dos intancias o crear peridi camente una nueva instancia para ser retornada por getInstancia. Es decir se puede permi tir un nmero variable de instancias. 2.1.6. Usos en el API de Java En el API de Java la clase java.lang.Runtime es una clase Singleton, tiene exact

amente Francisco Javier Martnez Juan Pgina 38

Gua de construccin de software en Java con patrones de diseo una nica instancia de la clase. No tiene constructores pblicos. Para conseguir una referencia a su nica instancia, otras clases deben llamar a su mtodo static getRuntime. 2.1.7. Patrones relacionados Puedes utilizar el patrn Singleton con muchos otros patrones. En particular, es a menudo utilizado con los patrones Abstract Factory, Builder, y Prototype. El patrn Singleton tiene alguna similitud con el patrn Cache Management. Un Single ton es funcionalmente similar a un Cache que contiene solamente un objeto. Francisco Javier Martnez Juan Pgina 39

Gua de construccin de software en Java con patrones de diseo 2.2. ITERATOR [GoF95] 2.2.1. Objetivo Define un interface que declara mtodos para acceder secuencialmente a los objetos de una coleccin. Una clase que accede a una coleccin solamente a travs de un interface independiente de la clase que implementa el interface. 2.2.2. Aplicabilidad El patrn Iterator se puede utilizar en los siguientes casos: Una clase necesita acceder al contenido de una coleccin sin llegar a ser dependie nte de la clase que es utilizada para implementar la coleccin, es decir sin tener que exponer su representacin interna. Una clase necesita un modo uniforme de acceder al contenido de varias coleccione s. Cuando se necesita soportar mltiples recorridos de una coleccin. 2.2.3. Solucin El diagrama de clases que muestra la organizacin de las clases e interfaces que p articipan en el patrn Iterator es el siguiente: IFIterator hasNextItem() getNextItem() <<Interface>> IFColeccion iterator() <<Interface>> crea Coleccion Iteratorcoge-objetos Patrn Iterator. A continuacin estn las descripciones de los papeles que juegan las clases e interf aces en la organizacin citada anteriormente: Coleccion Una clase en este papel encapsula una coleccin de objetos o valores. Francisco Javier Martnez Juan Pgina 41

Gua de construccin de software en Java con patrones de diseo IFIterator Un interface en este papel define los mtodos que acceden secuencialmente a los objetos que estn encapsulados en un objeto Coleccion. Iterator Una clase en este papel implementa un interface IFIterator. Sus instancias proporcionan acceso secuencial a los contenidos del objeto Coleccion asociado con el objeto Iterator. IFColeccion Las clases Coleccion normalmente toman responsabilidad para crear sus propios objetos Iterator. Es conveniente tener un modo consistente de preguntar a un objeto Coleccion para crear un objeto Iterator por si mismo. Para proporcionar esta consistencia, todas las clases Coleccion implementan un interface IFColeccion que declara un mtodo para crear objetos Iterator. 2.2.4. Consecuencias Es posible acceder a una coleccin de objetos sin conocer el cdigo de los objetos. Utilizando varios objetos Iterator, es simple tener y manejar varios recorridos al mismo tiempo, puesto que cada Iterator mantiene la pista de su recorrido. Es posible para una clase Coleccion proporcionar diferentes tipos de objetos Ite rator que recorran la coleccin en diferentes modos. Por ejemplo, una clase Coleccion que ma ntiene una asociacin entre la clave de los objetos y el valor de los objetos podra tener diferentes mtodos para crear Iterators que recorran slo la clave de los objetos y crear Itera tors que recorran slo el valor de los objetos. Las clases Iterator simplifican el cdigo de las colecciones, ya que el cdigo de lo s recorridos se encuentra en los Iterators y no en las colecciones. 2.2.5. Implementacin El interface IFIterator mostrado en el diagrama de clases del patrn Iterator cont iene un conjunto mnimo de mtodos. Es comn para los intefaces IFIterator definir mtodos adicionales cuando son tiles y son soportados por las clases Coleccion. En adicin a los mtodos para preguntar la existencia y coger el siguiente elemento de la coleccin, son comunes los siguientes mtodos: Para preguntar la existencia y coger el elemento anterior de la coleccin. Moverse al primero o al ltimo elemento de la coleccin. Coger el nmero de elementos del recorrido. En muchos casos, un algoritmo de recorrido de una clase Iterator requiere el acc eso a la estructura de datos interna de una clase Coleccion. Por esta razn, las clases Ite rator son a menudo implementadas como una clase interna privada de la clase Coleccion. Francisco Javier Martnez Juan Pgina 42

Gua de construccin de software en Java con patrones de diseo Un Iterator Null es un Iterator que no retorna objetos. Su mtodo hasNext siempre retorna false. Los Iterators Null son normalmente implementados como una simple clase que implementa el apropiado interface IFIterator. La utilizacin de Iterators Null pue de simplificar la implementacin de clases Coleccion y otras clases Iterator para eli minar la necesidad de que algn cdigo necesitase el manejo especial de un recorrido null. Las modificaciones para un objeto Coleccion mientras un Iterator recorre su cont enido puede causar problemas. Si las provisiones no son realizadas de acuerdo con tale s modificaciones, un Iterator podra retornar un conjunto inconsistente de resultado s. Tales potenciales inconsistencias incluyen saltarse objetos o retornar el mismo dos ve ces. El modo ms simple de manejar las modificaciones de una coleccin durante un recorri do por un Iterator es considerar que el Iterator es invalido despus de la modificacin. Pu edes implementar esto teniendo cada una de las clases Coleccion mtodos que modifiquen una coleccin incrementando un contador cuando ellos modifican la coleccin. Los objetos Iterator pueden luego detectar un cambio en su coleccin subyacente notando un cam bio en su contador de cambios. Si uno de los mtodos del objeto Iterator es llamado y not a que la coleccin subyacente ha cambiado, luego puede lanzar una excepcin. Una forma ms robusta de manejar las modificaciones de una coleccin rrido por un Iterator es asegurarse de que el Iterator retorna un conjunto de resultados. Hay varias formas de hacerlo. Por ejemplo tener un copia la coleccin, normalmente es la tcnica menos deseable porque es la ms memoria. durante un reco consistente completa de cara en tiempo y

2.2.6. Usos en el API de Java Las clases coleccin en el paquete java.util siguen el patrn Iterator. El inteface java.util.Collection juega el papel de IFColeccion. El paquete incluye un nmero d e clases que implementan el java.util.Collection. El interface java.util.Iterator juega el papel del IFIterator. Las clases en el paquete que implementan java.util.Collection definen las clases internas privadas que implem entan java.util.Iterator y juegan el papel Iterator. 2.2.7. Patrones relacionados Adapter El patrn Iterator es una forma especializada del patrn Adapter para accede r secuencialmente a los contenidos de una coleccin de objetos.

Factory Method Algunas clases Coleccion podran usar el patrn Factory Method para determinar que tipo de Iterator instanciar. Francisco Javier Martnez Juan Pgina 43

Gua de construccin de software en Java con patrones de diseo Null Object Iterators Null son algunas veces utilizados para implementar el patrn Null Object. Francisco Javier Martnez Juan Pgina 44

Gua de construccin de software en Java con patrones de diseo 2.3. STRATEGY [GoF95] 2.3.1. Objetivo Encapsula algoritmos relacionados en clases que son subclases de una superclase comn. Esto permite la seleccin de un algoritmo que varia segn el objeto y tambin le permi te la variacin en el tiempo. 2.3.2. Aplicabilidad Un programa tiene que proporcionar mltiples variantes de un algoritmo o comportamiento. Puedes encapsular las variantes de comportamiento en clases separadas que proporcionan un modo consistente de acceder a los comportamientos. Poner estos comportamientos en clases separadas significa que las clases que uti lizan estos comportamientos no necesitan conocer nada sobre como estn implementados. Estas clases tienen una superclase comn o interface que permite que las clases qu e las utilizan ignoren como seleccionar un comportamiento o que comportamiento es seleccionado. 2.3.3. Solucin El diagrama de clases que muestra la organizacin de las clases que participan en el patrn Strategy es el siguiente: StrategyConcreto1 StrategyConcreto2 StrategyAbstracto operacion() Cliente 0..110..11 utiliza Patrn Strategy. A continuacin estn las descripciones de los papeles que juegan las clases en la or ganizacin citada anteriormente: Francisco Javier Martnez Juan Pgina 45

Gua de construccin de software en Java con patrones de diseo Cliente Una clase en el papel de Cliente delega una operacin a una clase abstracta o interface. Esto hace que sin conocer la clase actual del objeto delegue la operacin hacia o como esa clase implementa la operacin. StrategyAbstracto Una clase en este papel proporciona una forma comn para acceder a la operacin encapsulada por sus subclases. Tambin se puede utilizar un interface para este papel. StrategyConcreto1, StrategyConcreto2 Las clases en este papel implementan diferentes implementaciones de la operacin que la clase Cliente delega. El patrn Strategy siempre sucede con un mecanismo para determinar el objeto StrategyConcreto que el objeto Cliente utilizar. Sin embargo, el mecanismo actual varia tanto que ningn mecanismo particular es incluido en el patrn. 2.3.4. Consecuencias El patrn Strategy permite que los comportamientos de los objetos Cliente sean determinados dinmicamente sobre un objeto base. El patrn Strategy simplifica los objetos Cliente para deducirlos de alguna respon sabilidad para seleccionar comportamientos o implementaciones de comportamientos alternati vos. Esto simplifica el cdigo de los objetos Cliente eliminando las expresiones if y switch . En algunos casos, esto puede incrementar tambin la velocidad de los objetos Cliente porque e llos no necesitan perder tiempo seleccionado un comportamiento. 2.3.5. Implementacin Es comn para las clases StrategyConcreto compartir algn comportamiento comn. Deberas factorizar el comportamiento comn que comparten en una superclase comn. Podra haber situaciones en las cuales ninguno de los comportamientos encapsulados en las clases StrategyConcreto es apropiado. Una forma comn de manejar estas situaciones es que el objeto Cliente tenga un null en lugar de una referencia a un objeto Strat egy. Esto significa tener que chequear por un null antes de llamar a un mtodo de un objeto Strategy. Si la estructura de un objeto Cliente tiene este inconveniente, consider utilizar el patrn Null Object. Francisco Javier Martnez Juan Pgina 46

Gua de construccin de software en Java con patrones de diseo 2.3.6. Usos en el API de Java El paquete java.util.zip contiene algunas clases que utilizan el patrn Strategy. Las clases CheckedInputStream y CheckedOutputStream utilizan ambas el patrn Strategy para procesar checksums sobre streams de bytes. Estas dos clases participan ambas com o clases Cliente. Los constructores para ambas clases tienen un argumento Checksum. Check sum es un interface que participa en el papel de StrategyAbstracto. Las dos clases que implementan el interface Checksum son: Adler32 y CRC32. Estas clases participan en el papel de StrategyConcreto. El siguiente diagrama representa las relaciones entre estas cl ases: CheckedInputStream Adler32 CRC32 CheckedOutputStreamChecksum <<Interface>> 1111utiliza 11 utiliza 1 1 Clases relacionadas con Checksum. 2.3.7. Patrones relacionados Adapter El patrn Adapter es estructuralmente similar al patrn Strategy. La diferen cia esta en el objetivo. El patrn Adapter permite a un objeto Cliente sacar su funcin pretendida originalmente mediante llamadas a mtodos de objetos que implementa un interface particular. El patrn Strategy proporciona objetos que implementa un interface par ticular con el propsito de alterar o determinar el comportamiento de un objeto Cliente. Flyweight Si hay muchos objetos Cliente, los objetos StrategyConcreto pueder est ar mejor implementados como Flyweights. Null Object El patrn Strategy es a menudo utilizado con el patrn Null Object. Template Method El patrn Template Method maneja comportamientos alternativos a travs de subclases ms que a travs de delegacin. Francisco Javier Martnez Juan Pgina 47

Gua de construccin de software en Java con patrones de diseo 2.4. OBSERVER [GoF95] 2.4.1. Objetivo Permite a los objetos captar dinmicamente las dependencias entre objetos, de tal forma que un objeto notificar a los objetos dependientes de l cuando cambia su estado, siend o actualizados automticamente. 2.4.2. Aplicabilidad Cuando una abstraccin tiene dos aspectos, uno dependiente de otro. Una instancia de una clase necesitar notificar a otros objetos cuando cambia su estado. La instancia de la otra clase necesitar ser notificada cuando un objeto sobre el que tiene dependencia cambia su estado. Encapsular estos aspectos en objetos diferentes permite variarlos y reutilizarlos independientemente. Cuando tienes una relacin de dependencia de uno a muchos que puede requerir que un objeto notifique a mltiples objetos que dependen de l cuando cambia su estado. 2.4.3. Solucin El diagrama de clases que muestra la organizacin de las clases e interfaces que p articipan en el patrn Observer es el siguiente: Observer registra para recibir notificaciones registra observers notifica Observable IFObservable addObserver(observador : IFObserver) removeObserver(observador : IFObserver) <<Interface>> IFObserver notify() <<Interface>> 10..*10..* Multicaster addObserver(observador : IFObserver) removeObserver(observador : IFObserver) 111 1 111 1 0..*0..* notifica Patrn Observer. Francisco Javier Martnez Juan Pgina 49

Gua de construccin de software en Java con patrones de diseo A continuacin estn las descripciones de los papeles que juegan las clases e interf aces en la organizacin citada anteriormente: IFObserver Un interface en este papel define un mtodo que es normalmente llamado notifica o actualiza. Un objeto Observable llama a este mtodo para proporcionar una notificacin de que su estado ha cambiado, pasndole los argumentos apropiados. En muchos casos, una referencia al objeto Observable es uno de los argumentos que permite al mtodo conocer que objeto proporciona la notificacin. Observer Las instancias de clases en este papel implementan el interface IFObserver y reciben notificaciones de cambio de estado de los objetos Observable. IFObservable Los objetos Observable implementan un interface en este papel. El interface define dos mtodos que permiten a los objetos Observer registrarse y desregistrarse para recibir notificaciones. Observable Una clase en este papel implementa el interface IFObservable. Sus instancias son las responsables de manejar la inscripcin de objetos IFObserver que quieren recibir notificaciones de cambios de estado. Sus instancias son tambin responsables de distribuir las notificaciones. La clase Observable no implementa directamente estas responsabilidades. En lugar de eso, delega estas responsabilidades a un objeto Multicaster. Multicaster Las instancias de una clase en este papel manejan la inscripcin de objetos IFObserver y enviarles notificaciones por medio de un objeto Observable. La delegacin de estas responsabilidades hacia una clase Multicaster permite que sus implementaciones sean reutilizadas por todas las clases Observable que implementan el mismo interface IFObservable o enviar notificaciones a objetos que implementan el mismo interface IFObserver. La siguiente figura resume las colaboraciones entre los objetos que participan e n el patrn Observer: 1:addObserver(:IFObserver) o:IFObservable 1.1:addObserver(:IFObserver) :Multicaster o:IFObservable :Multicaster :IFObserver2:notify(o) 2.1:notify(o) Diagrama de colaboracin. Francisco Javier Martnez Juan Pgina 50

Gua de construccin de software en Java con patrones de diseo Una descripcin ms detallada de las interacciones mostrada en la figura anterior es la siguiente: 1. Los objetos que implementan un interface IFObserver son pasados al mtodo addObserver de un objeto ObsevableIF. 1.1.El objeto IFObservable delega la llamada a addObserver a su objeto asociado Multicaster. Este aade el objeto IFObservable a la coleccin de objetos IFObserver que l mantiene. 2. El objeto IFObservable necesita notificar a otros objetos que son dependientes d e l que su estado ha cambiado. Este objeto inicializa la notificacin llamando al mtodo not ify de su objeto asociado Multicaster. 2.1.El objeto Multicaster llama al mtodo notify de cada uno de los objetos IFObserver de su coleccin. 2.4.4. Consecuencias El patrn Observer permite a un objeto enviar notificaciones a otros objetos sin q ue los objetos emisores o los objetos receptores de las notificaciones sean conscientes de las clases de los otros. Hay algunas situaciones en las que el patrn Observer puede tener imprevistos e in deseables resultados: El envo de notificaciones puede durar bastante tiempo si un objeto tiene un gran nmero de objetos a los que enviar notificaciones. Esto puede suceder porque un objeto tiene muchos observadores registrados directamente para recibir sus notificaciones. Esto tambin puede suceder porque un objeto tiene muchos observadores indirectamente porque sus notificaciones son en cascada por otros objetos. Un problema ms serio ocurre si hay dependencias en ciclo. Los objetos llaman cada uno a los mtodos notify de los otros hasta que se llena la pila excepcin StackOverflowError. Pensando seriamente, este problema fcilmente solucionado aadiendo una variable booleana interno a involucradas en el ciclo que detecte una notificacin recursiva, private boolean inNotify=false; public void notify (IFObservable source) { if (inNotify) return; inNotify=true; ...... Francisco Javier Martnez Juan Pgina 51 y se lanza una puede ser una de las clases seria algo as:

Gua de construccin de software en Java con patrones de diseo inNotify=false; }//notify (IFObservable) Cuando un objeto Observer recibe una notificacin, este conoce que objeto ha cambi ado, pero no conoce de que forma ha cambiado. Evitar requerir un objeto Observer para determinar que atributos de un objeto IFObservable ha cambiado. Esto es ms simple para un observador actuar sobre todos los atributos de los objetos IFObservable ms bie n que ir al problema de determinar cuales han cambiado y luego actuar sobre ellos. 2.4.5. Implementacin Un objeto Observable normalmente pasa una referencia a s mismo como parmetro aun mtodo notifiy de un objeto Observer. En la mayora de los casos, el objeto Observer necesita acceder a los atributos del objeto Observable para actuar sobre la noti ficacin. Aqu estn algunos modos de proporcionar este acceso: Aadir mtodos al interface IFObservable para retornar valores de los atributos. Est a es normalmente la mejor solucin. Sin embargo, solamente funciona si todas las cla ses que implementan el interface IFObservable tiene un conjunto comn de atributos par a que los objetos Observer acten sobre las notificaciones. Puedes tener mltiples interfaces IFObservable, con cada uno proporcionas acceso a los atributos para que los objetos Observer acten sobre las notificaciones. Para hacer este trabajo, los interfaces IFObserver deben declarar una versin de su mtodo notify para cada uno de los interfaces ObsevableIF. Est no es una solucin muy buena. Puedes pasar los atributos que necesitan los objetos IFObserver como parmetros a sus mtodos notify. La principal desventaja de esta solucin es que requiere objetos Observable que conozcan bastante sobre los objetos IFObserver para proporcionarlos con los valores correctos de los atributos. Puedes distribuir con el interface IFObservable y pasar los objetos Observable a los objetos IFObserver como instancias de su clase actual. Esto implica sobrecargar el mtodo notify del interface IFObserver, as que hay un mtodo notify para cada clase Observable que enviar notificaciones a los objetos IFObserver. La principal desventaja de este enfoque es que las clases Observer deben conocer las clases Observable que distribuirn notificaciones a sus instancias y conocer como sacar l os atributos que necesita de ellas. Por otro lado, si solamente una clase Observabl e enviar notificaciones a las clases Observer, entonces est es la mejor solucin. Esto no aade complejidad a ninguna de las clases. Sustituye una dependencia sobre un

nico interface por una dependencia sobre una nica clase. Entonces esto simplifica el diseo eliminando el interface IFObservable. Otra simplificacin que se hace frecuentemente en el patrn Observer es eliminar la clase Multicaster. Si una clase Observable es la nica clase que enva notificaciones a lo s objetos que implementan un interface particular, entonces no hay necesidad para utilizar una clase Multicaster. Otra razn de no tener una clase Multicaster es que un objeto Observa ble Francisco Javier Martnez Juan Pgina 52

Gua de construccin de software en Java con patrones de diseo nunca tendr que enviar notificaciones a ms de un objeto. En este caso, el manejo y envo de notificaciones a objetos Observer es tan simple que un clase Multicaster aade ms complejidad que beneficio. Podra no ser necesario o til notificar a los objetos Observer de cada cambio a un objeto Observable. Si este es el caso, puedes evitar las innecesarias notificaciones de cambios de estado y esperar hasta que un lote de cambios este completo para enviar las noti ficaciones. Si otro objeto realiza cambios en un estado de objeto Observable, entonces proporci onar una nica notificacin para un lote de cambios es ms complicado. Tendrs que aadir un mtodo a la clase de objetos Observable que otros objetos puedan llamar para indicar el comienzo de un lote de cambios de estado. Cuando un cambio de estado es parte de un lote, es te no debera causar que el objeto enve ninguna notificacin a sus observers registrados. T ambin tendrs que aadir un mtodo a la clase de objetos Observable que otros objetos llamen para indicar el fin del lote de cambios de estado. Cuando este mtodo es llamado, si ni ngn cambio de estado ha ocurrido desde el principio del lote, el objeto debera enviar notifi caciones a sus observers registrados. Si mltiples objetos inicializarn cambios de estado de un objeto Observable, entonc es determinara el fin de un lote de cambios podra ser ms complicado. Una buena forma de manejar esta complejidad es aadir un objeto adicional que coordine los cambios de estado inicializados por otros objetos y comprendiendo su lgica bien es suficiente para determinar el fin de un lote de cambios. El patrn Observer es normalmente utilizado para notificar a otros objetos que un estado de un objeto ha cambiado. Una variacin comn de esto es definir un interface IFObserva ble alterno que permita a los objetos que demandan que ellos reciban una notificacin antes de un cambio de estado. La razn normal para enviar notificaciones de cambios de estado despus de un cambio de estado es para permitir que el cambio se propague a otros objeto s. La razn normal para enviar una notificacin antes de un cambio de estado es que otros obje tos pueden vetar un cambio de estado. La forma normal de implementar esto es teniendo un ob jeto que lanza una excepcin para prevenir un cambio de estado pensado. 2.4.6. Usos en el API de Java El modelo de delegacin de eventos en Java es una forma especializada del patrn Obs erver.

Las clases cuyas instancias pueden ser fuente de eventos participan en el papel de Observable. Los interfaces escuchadores de eventos participan en el papel IFObse rver. Las clases que implementan los interfaces escuchadores de eventos participan en el p apel Observer. Como hay un nmero de clases que envan varias subclases de java.awt.AwtEvent a sus escuchadores, hay una clase Multicaster que ellos utiliz an llamada java.awt.AWTEventMulticaster. Francisco Javier Martnez Juan Pgina 53

Gua de construccin de software en Java con patrones de diseo 2.4.7. Patrones relacionados Adapter El patrn Adapter puede ser utilizado para permitir a los objetos que no implementen el interface requerido participar en el patrn Observer para recibir n otificaciones. Delegation El patrn Observer utiliza el patrn Delegation. Mediator El patrn Mediator es utilizado algunas veces para coordinar cambios de estado inicializados por mltiples objetos a un objeto Observable. Francisco Javier Martnez Juan Pgina 54

Gua de construccin de software en Java con patrones de diseo 2.5. PROTOTYPE [GoF95] 2.5.1. Objetivo Permite a un objeto crear objetos personalizados sin conocer su clase exacta o l os detalles de cmo crearlos. Su tarea es dar objetos prototipo a un objeto que inicializa la cre acin de objetos. El objeto de creacin e inicializacin crea objetos mandando a sus objetos prototipo que hagan una copia de si mismos. 2.5.2. Aplicabilidad Un sistema debe ser capaz de crear objetos sin conocer su clase exacta, como son creados, o que datos representan. Las clases sern instanciadas sin ser conocidas por el sistema hasta el tiempo de ejecucin. Los siguientes mtodos para la creacin de una gran variedad de objetos son indeseables: Las clases que inicializan la creacin de objetos crean directamente los objetos. Esto hace que ellos sean conscientes y dependientes de un gran nmero de otras clases. Las clases que inicializan la creacin de objetos crean los objetos indirectamente a travs de una clase factory method. Un factory method que es capaz de crear una gran variedad de objetos puede ser muy grande y difcil de mantener. Las clases que inicializan la creacin de objetos crean los objetos indirectamente a travs de una clase abstracta factory. Para que un abstracta factory sea capaz de crear una gran variedad de objetos debe tener una gran variedad de clases factory concretas en una jerarqua semejante a las clases que deben ser instanciadas. Los objetos diferentes que un sistema debe crear deben ser instancias de la misma clase que contienen diferentes estados de informacin o datos. Francisco Javier Martnez Juan Pgina 55

Gua de construccin de software en Java con patrones de diseo 2.5.3. Solucin El diagrama de clases que muestra la organizacin de las clases e interfaces que p articipan en el patrn Prototype es el siguiente: PrototypeConcreto1 clone() PrototypeConcreto2 clone() Prototype clone() Cliente operacion() 1..*11..*1 utiliza Patrn Prototype. A continuacin estn las descripciones de los papeles que juegan las clases e interf aces en la organizacin citada anteriormente: Cliente La clase Cliente crea nuevos objetos pidiendo al prototipo que se clone. Prototype Declara la interface del objeto que se clona. Suele ser una clase abstracta. PrototypeConcreto1, PrototypeConcreto2 Las clases en este papel implementan una operacin por medio de la clonacin de s mismo. 2.5.4. Consecuencias Un programa puede dinmicamente aadir y borrar objetos prototipo en tiempo de ejecucin. Esta es una ventaja que no ofrece ninguno de los otros patrones de creacin. Esconde los nombres de los productos especficos al cliente. El objeto cliente puede tambin ser capaz de crear nuevos objetos de tipos prototi po. Se pueden especificar nuevos objetos prototipo variando los existentes. La clase Cliente es independiente de las clases exactas de los objetos prototipo que utiliza. Tambin, la clase Cliente no necesita conocer los detalles de cmo construi r los objetos prototipo. Francisco Javier Martnez Juan Pgina 56

Gua de construccin de software en Java con patrones de diseo Los objetos de prototipo concretos implementan el interface Prototype , de esta forma el patrn Prototype se asegura de que los objetos prototipo proporcionan un conjunto consistente de mtodos para que los objetos clientes los utilicen. Se puede configurar una aplicacin cargando clases dinmicamente. No hay necesidad de organizar los objetos prototipos en ningn orden de jerarqua de clases. Las subclases son reducidas. 2.5.5. Implementacin Todas las clases en Java heredan un mtodo de la clase Object llamado clone. Un mto do clone de un objeto retorna una copia de ese objeto. Esto solamente se hace para instancias de clases que dan permiso para ser clonadas. Una clase da permiso para que su in stancia sea clonada si, y solo si, ella implementa el interface Cloneable. Si va a variar el nmero de prototipos se puede utilizar un administrador de proto tipos. Cmo implementar la operacin clone de los objetos prototipo es otra importante caracterstica de la implementacin. Hay dos estrategias bsicas para implementar la operacin clone: 1. Copia superficial significa que las variables de los objetos clonados contienen los mismos valores que las variables del objeto original y que todas las referencias al objeto son a los mismos objetos. En otras palabras, la copia superficial copia solamente el objeto que ser clonado, no los objetos a los que se refiere. 2. Copia profunda significa que las variables de los objetos clonados contienen los mismos valores que las variables del objeto original, excepto que estas variable s que se refieren a objetos realizan copias de los objetos referenciados por el objeto original. En otras palabras, la copia profunda copia el objeto que ser clonado y los objetos a los que se referencia. Implementar la copia profunda puede ser delicad o. Necesitars decidir si quieres hacer copia profunda o superficial de los objetos copiados indirectamente. Tambin necesitars ser cuidadoso con el manejo de las referencias circulares. La copia superficial es ms fcil de implementar porque todas las clases heredan un mtodo clone de la clase Object que hace esto. Sin embargo, a menos que una clase de ob jetos implemente el interface Cloneable, el mtodo clone rechazar trabajar. Si todos los objetos prototipo que tu programes utilizarn clonarse a s mismos por copia superficial, pu edes ahorrar tiempo declarando un interface Prototype que extienda el interface Clone able. De

esta forma todas las clases que implementen el interface Prototype tambin impleme ntarn el interface Cloneable. Francisco Javier Martnez Juan Pgina 57

Gua de construccin de software en Java con patrones de diseo 2.5.6. Usos en el API de Java El patrn Prototype es la esencia de los JavaBeans. Los JavaBeans son instancias d e clases que conforma ciertas convenciones de nombres. Las convenciones de nombres permit en a un bean crear un programa conociendo como particularizarlos. Despus de que un objeto bean ha sido particularizado para su uso en una aplicacin, el objeto es guardado en un fichero para ser cargado por la aplicacin mientras se esta ejecutando. Salvar un objeto a un f ichero para ser cargado ms tarde por otra aplicacin es un modo de posponer en el tiempo la cre acin de objetos. 2.5.7. Patrones relacionados Composite El patrn Prototype es utilizado a menudo con el patrn Composite. Abstract Factory El patrn Abstract Factory puede ser una buena alternativa al pat rn Prototype donde los cambios dinmicos que el patrn Prototype permite para los objet os prototipo no son necesarios. Pueden competir en su objetivo, pero tambin pueden c olaborar entre s. Facade La clase cliente normalmente acta comnmente como un facade que separa las otras clases que participan en el patrn Prototype del resto del programa. Factory Method El patrn Factory Method puede ser una alternativa al patrn Prototype cuando la paleta de objetos prototipo nunca contiene ms de un objeto. Decorator El patrn Prototype es utilizado a menudo con el patrn Decorator. Francisco Javier Martnez Juan Pgina 58

Gua de construccin de software en Java con patrones de diseo 2.6. COMPOSITE [GoF95] 2.6.1. Objetivo Permite construir objetos complejos mediante composicin recursiva de objetos simi lares. El patrn Composite tambin permite que los objetos del rbol sean manipulados por un manejador consistente, para requerir todos los objetos hay una superclase o un i nterfaz comn. Permite a los clientes tratar de la misma manera tanto a objetos individual es como a compuestos. 2.6.2. Aplicabilidad Tienes un objeto complejo que quieres descomponer en una jerarqua de objetos. Quieres minimizar la complejidad del conjunto de la jerarqua minimizando el nmero de tipos diferentes de objetos hijo en el rbol que los objetos compuestos necesit an para formarse. Los clientes no conocen la diferencia entre los objetos inidividuales y los grup os. 2.6.3. Solucin Minimiza la complejidad de un objeto composite organizado en jerarquias parte-to do proporcionando una superclase para todos los objetos de la jerarqua y una supercl ase abstracta para todos los composites de la jerarquia. A continuacin se muestra el diagrama de clases del patrn Composite: Francisco Javier Martnez Juan Pgina 59

Gua de construccin de software en Java con patrones de diseo ComponenteConcreto1 operacion() ComponenteConcreto2 operacion() CompositeConcreto1 operacion() add(ab : ComponenteAbstracto) remove(ab : ComponenteAbstracto) getChild(id : int) CompositeConcreto2 operacion() add(ab : ComponenteAbstracto) remove(ab : ComponenteAbstracto) getChild(id : int) Cliente ComponenteAbstracto operacion() CompositeAbstracto operacion() add(ab : ComponenteAbstracto) remove(ab : ComponenteAbstracto) getChild(id : int) * hijos .......... .............. Patrn Composite. Ahora mostramos las descripciones de las clases que participan en este patrn: ComponenteAbstracto El ComponenteAbstracto es una clase abstracta y la superclase comn de todos los objetos que estn en el rbol de objetos para formar un objeto composite. Los objetos composite normalemente tratan a los objetos que ellos contienen como instancias del ComponenteAbstracto. Los clientes de los objetos compositen los tratan normalmente como instancias del ComponenteAbstracto. ComponenteConcreto1, ComponenteConcreto2, .... Las instancias de estas clases son utilizadas como hojas en la organizacin del rbol. Una hoja no tiene hijos. Definen el comportamiento de los objetos primitivos. CompositeAbstracto El CompositeAbstracto es la superclase abstracta de todsos los objetos composite que participant en el patrn Composite. Define el comportamiento de los objetos que tienen hijos. Almacena los hijos. El CompositeAbstracto define y proporciona las implementaciones por defecto para los mtodos para manejar los componentes de los objetos composite. El mtodo add aade un componente a un objeto composite. El mtodo remove borra un componente del Francisco Javier Martnez Juan Pgina 60

Gua de construccin de software en Java con patrones de diseo objeto composite. El mtodo getChild retorna una referencia a un objeto componente de un objeto composite. CompositeConcreto1, CompositeConcreto2, ... Las instancias de estas clases son objetos composite que utilizan otras instancias del ComponenteAbstracto. Implementan las operaciones con los hijos en la interfaz. Cliente Manipula los objetos en la composicin a travs de la interfaz de la clase ComponenteAbstracto. La clase abstracta composite CompositeAbstracto no es necesaria cuando slo hay un a clase concreta composite CompositeConcreto. 2.6.4. Consecuencias Hay una jerarqua de objetos tan complejos como se requieran. El cliente es simple. Los objetos cliente de un ComponenteAbstracto pueden trata r simplemente con un ComponenteAbstracto, sin tener que conocer a ninguna de las subclases del ComponenteAbstracto. Si un cliente llama a un mtodo de un ComponenteAbstracto que es supuestamente realizar una operacin y el objeto ComponenteAbstracto es un objeto CompositeAbstracto, entonces delegar esta operacin a los objetos ComponenteAbstracto que lo constituyen. Anlogamente, si un objeto cliente llama a un mtodo de un objeto ComponenteAbstracto que no es un CompositeAbstracto y el mtodo requiere alguna informacin contextual, entonces el ComponenteAbstracto delegar la peticin de informacin contextual a su padre. El principal beneficio del patrn Composite es que permite a los clientes de un ob jeto composite y a los objetos que lo constituyen desconocer la clase especfica de los objetos con los que tratan. Se simplifica la adicin de nuevos objetos. El diseo es ms general. Se dificulta el control de los tipos de composiciones vlidas. Deben hacerse chequ eos en tiempo de ejecucin. 2.6.5. Implementacin Si las clases que participan en el patrn Composite implementan alguna operacin por delegacin de estas a sus objetos padre, entonces el mejor modo para onservar velo cidad y simplicidad es teniendo en cada instancia del ComponenteAbstracto una referencia a su padre. Es importante implementar el puntero al padrede una forma que se asegure la consistencia entre padre e hijo. Siempre debera ser que un ComponenteAbstracto

identifiquea un CompositeAbstracto como su padre, si y slo si, el CompositeAbstra cto lo Francisco Javier Martnez Juan Pgina 61

Gua de construccin de software en Java con patrones de diseo identifica como uno de sus hijos. La mejor forma para obligar esto es modificar las referencias al padre y al hijo solamente en la clase CompositeAbstracto aadiendo y quitando mt odos. Compartir componentes entre muchos padres utilizando el patrn Flyweight es una fo rma de ahorrar memoria. Sin embargo, es difcil compartir componentes correctamente mante niendo las referencias a los padres. La clase CompositeAbstracto podra proporcionar una implementacin por defecto para manejar los hijos de los objetos composite. Sin embargo, es muy comn que los comp osite concretos sobrescriban esta implementacin. El patrn Composite es algunas veces implementado con clases que no comparten una superclase comn, pero comparten un interface comn. Si una clase concreta composite delega una operacin a los objetos que lo constitu yen, entonces cachear el resultado de la operacin podra mejorar el rendimiento. Si una clase concreta composite cachea el resultado de una operacin, entonces es importante qu e los objetos que constituyen el compoiste notifiquen al objeto composite que pueden s er invalidos sus valores cacheados. 2.6.6. Usos en el API de Java El paquete java.awt.swing contiene un buen ejemplo del patrn Composite. Su clase Component cubre el papel del ComponenteAbstracto. Su clase Container cubre el pa pel del CompositeAbstracto Tiene un nmero de clases en el papel ComponenteConcreto, incluyendo Label, TextField, y Button. Enre las clases en el papel CompositeConc reto se incluyen Panel, Frame, y Dialog. 2.6.7. Patrones relacionados Chain of Responsibility El patrn Chain of Resposibility puede ser combinado con e l patrn Composite para aadir links del hijo al padre (para propagar responsabilidade s hacia arriba), de tal forma que, los hijos puedan conseguir informacin sobre un progeni tor sin tener que conocer que progenitor proporciona la infomacin. Decorator Generalmente se usan juntos. Flyweight Para compartir componentes, cuando no haya referencias a los padres. Iterator Para recorrer los hijos en un composite. Francisco Javier Martnez Juan Pgina 62

Gua de construccin de software en Java con patrones de diseo Vistor Se puede utilizar el patrn Visitor para encapsular operaciones en una clas e simple, que de lo contrario podra propagarse a trves de muchas clases y agregar comportamiento a las clases del patrn Composite.. Francisco Javier Martnez Juan Pgina 63

Gua de construccin de software en Java con patrones de diseo 2.7. DECORATOR [GoF95] 2.7.1. Objetivo Extiende la funcionalidad de un objeto dinmicamente de tal modo que es transparen te a sus clientes, utilizando una instancia de una subclase de la clase original que dele ga las operaciones al objeto original. Provee una alternativa muy flexible para agregar funcionalid ad a una clase. 2.7.2. Aplicabilidad Hay una necesidad de extender la funcionalidad de una clase, pero no hay razones para extenderlo a travs de la herencia. Hay la necesidad de extender dinmicamente la funcionalidad de un objeto y quizs quitar la funcionalidad extendida. 2.7.3. Solucin El diagrama de clases que muestra la estructura general del patrn Decorator es el siguiente: 1 ComponenteConcreto operacion1() operacion2() DecoratorConcretoA operacion1() operacion2() DecoratorConcretoB operacion1() operacion2() ComponenteAbstracto operacion1() operacion2() DecoratorAbstracto operacion1() operacion2() 1 extiende Patrn Decorator. Francisco Javier Martnez Juan Pgina 65

Gua de construccin de software en Java con patrones de diseo A continuacin estn las descripciones de los papeles que juegan las clases de la fi gura anterior en el patrn Decorator: ComponenteAbstracto Una clase abstracta en este papel es la superclase comn de todos los objetos componente pueden potencialmente ser extendidos a travs del patrn Decorator. En algunos casos los objetos componente que son extendidos no tienen una superclase comn pero implementan un interface comn. En este caso, el interface comn ocupa el lugar de la clase abstracta. ComponenteConcreto El patrn Decorator extiende las clases en este papel utilizando objetos que delegan a instancias de una clase ComponenteConcreto. DecoratorAbstracto La clase abstracta en este papel es la superclase comn para las clases decorator. Las instancias de esta clase tienen responsabilidad para mantener una referencia a los objetos componente que delegan en los objetos decorator. Esta clase tambin a menudo sobrescribe todos los mtodos que hereda de la clase ComponenteAbstracto, asi que, las instancias simplemente llaman al mtodo del objeto componente que delega en el objeto decorator. Esta implementacin por defecto proporciona exactamente el comportamiento necesario por los mtodos cuyo comportamiento no esta siendo extendido. DecoratorConcretoA, DecoratorConcretoB, .... Estas clases concretas decorator extienden el comportamiento de los mtodos que ellas heredan de la clase DecoratorAbstracto de cualquier forma necesaria. 2.7.4. Consecuencias El patrn Decorator proporciona mayor flexibilidad que la herencia. Esto te permit e alterar dinmicamente el comportamiento de los objetos individuales aadiendo y borrando decorators. La herencia, por otra parte, determina la naturaleza de todas las in stancias de una clase estticamente. Utilizando diferentes combinaciones de unos pocos tipos distintos de objetos dec orator, puedes crear muchas combinaciones distintas de comportamientos. Para crear esos diferentes tipos de comportamiento con la herencia se requiere que definas muchas clases di stintas. La flexibilidad de los objetos decorator los hace mas propenso a errores que la herencia. Por ejemplo, es posible combinar objetos decorator de diferentes formas que no funci onen, o crear referencias circulares entre los objetos decorator. Francisco Javier Martnez Juan Pgina 66

Gua de construccin de software en Java con patrones de diseo Utilizando el patrn Decorator generalmente se tienen menos clases que utilizando la herencia. Teniendo menos clases se simplifica el diseo y la implementacin de los programas. Por otro lado, utilizando el patrn Decorator normalmente se tienen ms objetos. El gran nmero de objetos puede realizar el debugging (encontrar y reparar errores de un programa) ms complicado. Una ltima dificultad asociada al patrn Decorator es que un objeto decorator no es un objeto componente, por lo que se pierde la identidad del objeto. Los objetos componente se esconden detrs de los objetos decorator. 2.7.5. Implementacin La mayora de las implementaciones del patrn Decorator son ms sencillas que el caso general. Aqu estn algunas de las simplificaciones ms comunes: Si solamente hay una clase ComponenteConcreto y ninguna clase ComponenteAbstracto, entonces la clase DecoratorAbstracto es normalmente una subclase de la clase ComponenteConcreto. A menudo el patrn Decorator es utilizado para delegar a un nico objeto. En este caso, no hay necesidad de tener la clase DecoratorAbstracto para mantener una coleccin de referencias. Slo conservando una nica referencia es suficiente. Si solamente hay una clase decorator, entonces no hay necesidad de tener una cla se DecoratorAbstracto separada. Se puede fusionar las responsabilidades de la clase DecoratorAbstracto con otras de la clase concrete decorator. Podra tambin ser razonable prescindir de la clase DecoratorAbstracto si hay dos clases concretas decorator, pero no si hay ms de dos 2.7.6. Patrones relacionados Delegation El patn Decorator es una forma estructurada de aplicar el patrn Delegat ion. Filter El patrn Filter es una versin especializada del patrn Decorator enfocada en la manipulacin de stream de datos. Strategy El patrn Decorator es til para organizar las cosas que suceden antes o despus de que se llaman a los mtodos de otro objeto. Si quieres planificar diferen tes cosas que ocurren en medio de las llamadas a un mtodo considera utilizar el patrn Strate gy. Template Method El patrn Template Method es otra alternativa al patrn Decorator qu e permite variar el comportamiento en medio de una llamada a un mtodo en lugar de a ntes o despus. Francisco Javier Martnez Juan Pgina 67

Gua de construccin de software en Java con patrones de diseo Adapter Un decorador solo cambia las responsabilidades del objeto, no su interfa ce. El patrn Adapter cambia el interface. Composite Este patrn esta relacionado con el patrn Decorator, pero no es lo mismo. No est pensado para la agregacin de objetos. Francisco Javier Martnez Juan Pgina 68

Gua de construccin de software en Java con patrones de diseo 2.8. FACTORY METHOD [GoF95] 2.8.1. Objetivo Tu escribes una clase para reutilizar con tipos arbitrarios de datos. Tu organiz as esta clase de tal forma que se puedan instanciar otras clases sin depender de ninguna de las c lases que puedan ser instanciadas. La clase reutilizable es capaz de permanecer independie nte de las otras clases instanciadas delegando la eleccin de que clase instanciar a otros ob jetos y referirse a los objetos recin creados a travs de un interface comn. Define una inte rface para crear un objeto, dejando a las subclases decidir el tipo especfico. Permite delegar la responsabilidad de instanciacin a las subclases. 2.8.2. Aplicabilidad Debera ser posible organizar una clase de tal forma que se puedan crear objetos q ue hereden de una clase dada o que implementen un interface dado. Para ser reutiliz able la clase debera crear objetos sin conocer que subclases de una clase dada estn disponibles o que clases que implementan un interface dado estan disponibles. Es te conocimiento de uso especfico debera de proceder de una clase de uno especfico separada. Una clase no puede anticipar la clase de objetos que debe crear. Una clase quiere a sus clases derivadas para especificar los objetos a crear. Las clases delegan la responsabilidad a una de varias subclases y se quiere loca lizar que subclase es la delegada. 2.8.3. Solucin El diagrama de clases que muestra la organizacin de las clases e interfaces que p articipan en el patrn Factory Method es el siguiente: Francisco Javier Martnez Juan Pgina 69

Gua de construccin de software en Java con patrones de diseo ProductoConcreto operacion1() operacion2() Factory crearProducto(discriminador) : Producto Producto operacion1() operacion2() ** crea IFFactory crearProducto(discriminador) : Producto <<Interface>> PedirCreacion nuevoProducto()*1* 1 utiliza * 1* 1pedir creacion creador solicitante 1 11 Patrn Factory Method. A continuacin estn las descripciones de los papeles que juegan las clases e interf aces en la organizacin citada anteriormente: Producto Una clases en este papel es una superclase abstracta de objetos producidos por el patrn Factory Method. Define la interfaz de los objetos que crea el patrn Factory Method. ProductoConcreto Esta es alguna de las clases concretas que son instanciadas por los objetos que participan en el patrn Factory Method. Implementa la interfaz del producto. Si estas clases no comparten una lgica comn, entonces el papel del producto puede ser realizado por un interface en lugar de una clase abstracta. PedirCreacion Esta clase es una clase independiente que se necesita para crear clases especficas. Esto lo hace indirectamente a travs de una instancia de una clase Factory. IFFactory Es un interface. Los objetos que crean objetos producto por peticin de objetos de la clase PedirCreacion deben implementar este interface. Los interfaces de este tipo declaran un mtodo que es llamado por un objeto de la clase PedirCreacion para crear objetos de productos concretos. Este mtodo tiene argumentos que son necesarios para deducir la clase a instanciar. Factory Esta es la clase que implementa adecuadamente el interface IFFactory y tiene un mtodo para crear objetos ProductoConcreto.

Francisco Javier Martnez Juan Pgina 70

Gua de construccin de software en Java con patrones de diseo 2.8.4. Consecuencias Las primeras consecuencias de utilizar el patrn Factory Method son las iguientes: La clase PedirCreacion es independiente de la clase de los objetos de los produc tos concretos que son actualmente creados. El conjunto de clases Producto que pueden se instanciadas podra cambiar dinmicamente. 2.8.5. Implementacin En situaciones donde todos los productos concretos son conocidos por anticipado, el interface del producto podra no ser necesario. En estas situaciones , el nico bene ficio de utilizar el patrn Factory Method es que la clase PedirCreacion se mantiene indepe ndiente de las clases de los productos concretos actuales instanciadas. Esta forma de traba jar es que la clase PedirCreacion se refiere directamente a un objeto factory. Este objeto fac tory tiene un mtodo crearProducto implementado con la lgica necesaria para instanciar la clase c orrecta del producto concreto. Si cada clase que implementa un interface producto crea solamente un tipo de pro ducto concreto, entonces el mtodo crearProducto definido por el interface podra no neces itar ningn parmetro. Sin embargo, si los objetos factory requieren crear muchos tipos d e objetos producto entonces su mtodo crearProducto necesita tener los parmetros necesarios para deducir que clase producto instanciar. Parametrizar los mtodos crearProducto a menudo es algo as: Image crearImagen (String ext) { if (ext.equals("gif")) return new GIFImage(); if (ext.equals("jpeg")) return new JPEGImage(); ..... }//crearImagen(String) Esta secuencia de cdigo de palabras clave if funciona bien para mtodos crearProduc to que tiene un conjunto fijo de clases producto que instanciar. Para escribir un mt odo crearProducto que maneje un variable o gran nmero de clase producto puedes utiliz ar varios objetos que indiquen que clase instanciar como claves en una tabla hash, con objetos java.lang.reflect.Constructor por valores. Utilizando esta tcnica, buscas el valo r de un

argumento en la tabla hash y utilizas el objeto Constructor que esta como su val or en la tabla hash para intanciar el objeto deseado. Francisco Javier Martnez Juan Pgina 71

Gua de construccin de software en Java con patrones de diseo Otro punto que ilustra el segmento de cdigo es que los mtodos de creacin son un lug ar razonable para encontrar palabras clave switch o cadenas de palabras if. En much as situaciones, la presencia de palabras switch o cadenas de palabras if en el cdigo indican que un mtodo debera ser implementado como un mtodo polimrfico. Los mtodos de creacin no pueden ser implementados utilizando polimorfismo, porque el polimorfismo sola mente funciona despus de que un objeto ha sido creado. Para muchas implementaciones del patrn Factory Method, los argumentos que los mtod os crearProducto de los objetos factory tienen un conjunto de valores predeterminad os. A menudo es conveniente para la clase Factory definir nombres simblicos para cada u no de estos valores predeterminados. Las clases que piden a la clase Factory que cree objetos pueden utilizar estas constantes que definen los nombres simblicos para especific ar el tipo de objeto que debe ser creado. 2.8.6. Usos en el API de Java El API de Java utiliza el patrn Factory Method en diferentes lugares para permiti r la integracin del entorno del applet con el programa que lo contiene. Por ejemplo, c ada objetro URL tiene un objeto URLConnection asociado. Puedes utilizar los objetos URLConne ction para leer los bytes de na URL. Los objetos URLConnection tambin tienen un mtodo llamado getContent que retorna el contenido del paquete URL en un tipo apropiado de objeto Por ejemplo, si la URL contiene un fichero gif, entonces el mtodo getConte nt del objeto URLConnection retorna un objeto Image. Los objetos URLConnection juegan el papel de pedir la creacin del patrn Factory Method. Estos objetos delegan el trabajo del mtodo getContent a un objeto ContentHandler. ContentHandler es una clase abstracta que sirve como una clase Producto que sabe como manejar un tipo especfico de contenido. La forma en que un objeto URLConnection consigue un objeto ContentHandler es a travs de un objeto ContentHandlerFactory. La clase ContentHandlerFactory es una clase abstracta que participa en el patrn Factory Method como un interface IFFactory. La clase URLConnection tambin tiene un mtodo llamado setContentHandlerFactory. Los programas que contienen applets llaman a ese mtodo para proporcionar un objeto fa ctory utilizado por todos los objetos URLConnection. 2.8.7. Patrones relacionados Abstract Factory El patrn Factory Method es til para construir s para un propsito especfico sin que la peticin de construccin especficas que sern intanciadas. Si necesitas crear un cojunto relacionados o dependientes, entonces el patrn Abstract Factory objetos individuale conozca las clases de algunos objetos es ms apropiado pa

ra este uso. Francisco Javier Martnez Juan Pgina 72

Gua de construccin de software en Java con patrones de diseo Template Method El patrn Factory Method es a menudo utilizado con el patrn Template Method. Prototype El patrn Prototype proporciona un modo alternativo para un objeto de trabajar con otros objetos sin conocer los detalles de su construccin. El patrn Pr ototype especfica la clase de objetos a crear usando una instancia prototpica, y creando l os objetos mediante una copia de este prototipo. Este patrn no necesita derivar del interfac e IFFactory. Sin embargo puede requerir una requerir una operacin de inicializacin e n la clase Producto, esta operacin no la necesita el patrn Factory Method. Francisco Javier Martnez Juan Pgina 73

Gua de construccin de software en Java con patrones de diseo Gua de construccin de software en Java con patrones de diseo STATE [GoF95] 2.9.1. Objetivo Encapsula los estados de un objeto como objetos separados, cada pertenencia en u na subclase separada de una clase abstracta estado. Permite a un objeto cambiar su comportamiento cuando su estado interno cambia. El objeto parecer haber cambiado de clase. 2.9.2. Aplicabilidad El comportamiento de un objeto es determinado por un estado interno que cambia e n respuesta a los eventos. Debe cambiar su comportamiento en tiempo de ejecucin cuando cambie su estado. La organizacin de la lgica que maneja un estado de un objeto debera ser capaz de cambiar a muchos estados sin llegar a ser una gran cantidad de cdigo inmanejable. Las operaciones tienen sentencias condicionales largas que dependen del estado d el objeto. Este estado es representado por una constante enumerada. A menudo, varia s operaciones contendrn esta misma estructura condicional. Este patrn sita cada rama de la sentencia condicional en una clase separada. Esto permite tratar el e stado de un objeto como un objeto que puede variar de forma independiente a otros objetos. 2.9.3. Solucin El diagrama de clases que muestra la organizacin de clases que participan en el p atrn State es el siguiente: EstadoConcreto1 operacion1() operacion2() procesarEvento(evento) : Estado EstadoConcreto2 operacion1() operacion2() procesarEvento(evento) : Estado Estado operacion1() operacion2() procesarEvento(evento) : Estado Contexto estadoActual : Estado utiliza Patrn State. ........ Francisco Javier Martnez Juan Pgina 75