Arquitectura del Software Curso 2003/2004

Captulo 3

Patrones de Diseo

Jess Garca Molina Departamento de Informtica y Sistemas Universidad de Murcia http://dis.um.es/~jmolina

Contenidos
Introduccin a los patrones de diseo GoF Patrones de creacin Patrones estructurales Patrones de comportamiento

Patrones de diseo

Arquitectura software y patrones

Una arquitectura orientada a objetos bien estructurada est llena de patrones. La calidad de un sistema orientado a objetos se mide por la atencin que los diseadores han prestado a las colaboraciones entre sus objetos. Los patrones conducen a arquitecturas ms pequeas, ms simples y ms comprensibles G. Booch
Patrones de diseo 3

Diseo orientado a objetos

Disear software orientado a objetos es difcil pero disear software orientado a objetos reutilizable es ms difcil todava. Diseos generales y flexibles son muy difciles de encontrar la primera vez Qu conoce un programador experto que desconoce uno inexperto? Reutilizar soluciones que funcionaron en el pasado: EXPERIENCIA
Patrones de diseo 4

Patrones
Describen un problema recurrente y una solucin. Cada patrn nombra, explica, evala un diseo recurrente en sistemas OO. Elementos principales: Nombre Problema Solucin: Descripcin abstracta Consecuencias
Patrones de diseo 5

Granularidad
Patrones de Cdigo
Nivel de lenguaje de programacin

Frameworks
Diseos especficos de un dominio de aplicaciones.

Patrones de Diseo
Descripciones de clases cuyas instancias colaboran entre s que deben ser adaptados para resolver problemas de diseo general en un particular contexto. Un patrn de diseo identifica: Clases, Instancias, Roles, Colaboraciones y la distribucin de responsabilidades.
Patrones de diseo 6

Patrones y frameworks
Un framework es una coleccin organizada de clases que constituyen un diseo reutilizable para una clase especfica de software. Necesario adaptarlo a una aplicacin particular. Establece la arquitectura de la aplicacin Diferencias:
Patrones son ms abstractos que los frameworks Patrones son elementos arquitecturales ms pequeos Patrones son menos especializados
Patrones de diseo 7

Modelo-Vista-Control
Utilizado para construir interfaces de usuario en Smalltalk-80. Basado en tres tipos de objetos:
Modelo: objetos del dominio Vista: objetos presentacin en pantalla (interfaz de usuario) Controlador: define la forma en que la interfaz reacciona a la entrada del usuario.

Desacopla el modelo de las vistas.

Patrones de diseo

90 80 70 60 50 40 30 20 10 0 1er trim. 2do trim. 3er trim. 4to trim. Este Oeste Norte

2tr 4tr 1tr 3tr

Vistas

Modelo
t1=20 t2=25 t3=90 t4=20

Este Oeste Norte

1tr. 20 30 47

2tr. 25 38 47

3tr. 4tr. 90 20 32 32 45 45

Modelo-Vista-Control
Utiliza los siguientes patrones: Observer Composite Strategy Decorator Factory method

Patrones de diseo

10

Plantilla de definicin
Nombre Propsito
Qu hace?, Cul es su razn y propsito?, Qu cuestin de diseo particular o problema aborda?

Sinnimos Motivacin
Escenario que ilustra un problema particular y cmo el patrn lo resuelve.

Patrones de diseo

11

Plantilla de definicin
Aplicabilidad
En qu situaciones puede aplicarse?, Cmo las reconoces?, ejemplos de diseos que pueden mejorarse.

Estructura
Diagramas de clases que ilustran la estructura

Participantes
Clases que participan y sus responsabilidades

Colaboraciones
Diagramas de interaccin que muestran cmo colaboran los participantes.
Patrones de diseo 12

Plantilla de definicin
Consecuencias
Cmo alcanza el patrn sus objetivos?, Cules son los compromisos y resultados de usar el patrn?, Alternativas, Costes y Beneficios

Implementacin
Tcnicas, heursticas y consejos para la implementacin Hay cuestiones dependientes del lenguaje?

Ejemplo de Cdigo Usos conocidos Patrones relacionados

Patrones de diseo 13

Clasificacin
Propsito Creacin
mbito Clase
Factory Method

Estructural
Adapter

Comportamiento
Interpreter Template Method Chain of Responsability Command Iterator Mediator Memento Observer State Strategy Visitor

Objeto

Abstract Factory Builder Prototype Singleton

Adapter Bridge Composite Decorator Facade Flyweight Proxy

Patrones de diseo

14

A qu ayudan los patrones?

Encontrar los objetos
Tarea difcil Debemos considerar: encapsulacin, flexibilidad, dependencias, reutilizacin, extensibilidad, rendimiento,.. Clases del anlisis vs. Clases del diseo Clases del diseo no tienen contrapartida en el dominio Strategy, State, Prototype,... Clases del diseo son claves para hacer el sistema ms flexible.

Patrones de diseo

15

A qu ayudan los patrones?

Determinar granularidad de los objetos
Facade, Flyweight, Builder, Visitor,..

Especificar interfaces
Memento, Decorator, Proxy,..

Especificar implementacin de clases

Muchos patrones dependen de la distincin entre herencia de implementacin y herencia de interfaces Observer, State, Chain of Responsability,

programar hacia la interfaz, no hacia la implementacin

16

A qu ayudan los patrones?

Especificar implementacin de clases
programar hacia la interfaz, no hacia la implementacin

No declarar variables de clases concretas sino abstractas. Patrones de creacin permiten que un sistema est basado en trminos de interfaces y no en implementaciones.
Patrones de diseo 17

A qu ayudan los patrones?

Favorecen la reutilizacin HERENCIA
- Definicin esttica - Sencilla de usar - Fcil modificar la implem. estticamente pero no en t.e. - Se rompe la encapsulacin

COMPOSICION
- Definicin dinmica - Uso ms complicado - Es posible cambiar en tiempo de ejecucin - No se rompe la encapsulacin - Requiere que se satisfaga cierta interfaz -Se puede sustituir la implem. en tiempo de ejecucin.

A qu ayudan los patrones?

Favorecer la reutilizacin
Favorecer la composicin sobre la herencia de clases

Herencia y composicin trabajan juntas Se suele abusar de la herencia. Los diseos suelen ser ms reutilizables si dependen de la composicin.

Patrones de diseo

19

A qu ayudan los patrones?

Delegacin
Forma de hacer que la composicin sea tan potente como la herencia. Un objeto receptor delega operaciones en su delegado Delegacin vs. forwarding Software ms flexible pero ms complicado. Difcil saber cuando conviene usarla. Presente en muchos patrones: State, Strategy, Visitor,.. Caso extremo de composicin, muestra que siempre puede sustituirse la herencia por composicin.
Patrones de diseo 20

Delegacin
Rectangulo Window area() area() +rectangulo ancho alto

return rectangulo.area

return ancho * alto

Patrones de diseo

21

Ejercicio
Supuesto Eiffel, C++ o Java, seala tres formas de escribir una rutina de ordenacin de modo que la comparacin que usa para comparar no sea fija.

Patrones de diseo

22

A qu ayudan los patrones?

La clave para la reutilizacin es anticiparse a los nuevos requisitos y cambios, de modo que los sistemas evolucionen de forma adecuada. Cada patrn permite que algunos aspectos de la estructura del sistema puedan cambiar independientemente de otros aspectos. Facilitan reuso interno, extensibilidad y mantenimiento.

Patrones de diseo

23

Causas comunes de rediseo

i) Crear un objeto indicando la clase. ii) Dependencia de operaciones especficas iii) Dependencia de plataformas hardware o software iv) Dependencia sobre representacin de objetos. v) Dependencias de algoritmos vi) Acoplamiento fuerte entre clases vii) Extender funcionalidad mediante subclases viii) Incapacidad de cambiar clases convenientemente
Patrones de diseo 24

Patrones frente a esos peligros

i) Abstract factory, Method factory, Prototype ii) Chain of Responsability, Command iii) Abstract factory, Bridge iv) Abstract factory, Bridge, Memento, Proxy, v) Builder, Iterator, Strategy, Template Method, Visitor vi) Abstract factory, Bridge, Chain of Responsability, Command, Facade, Mediator, Observer vii) Bridge, Chain of Responsability, Composite, Decorator, Observer, Strategy viii) Adapter, Decorator, Visitor
Patrones de diseo 25

Cmo seleccionar un patrn?

Considera de que forma los patrones resuelven problemas de diseo Lee la seccin que describe el propsito de cada patrn Estudia las interrelaciones entre patrones Analiza patrones con el mismo propsito Examina las causas de redisear Considera que debera ser variable en tu diseo
Patrones de diseo 26

Cmo usar un patrn?

Lee el patrn, todos sus apartados, para coger una visin global. Estudia la Estructura, Participantes y Colaboraciones Mira el ejemplo de cdigo Asocia a cada participante del patrn un elemento software de tu aplicacin. Implementa las clases y mtodos relacionados con el patrn.
Patrones de diseo 27

Patrones de Creacin
Abstraen el proceso de creacin de objetos. Ayudan a crear sistemas independientes de cmo los objetos son creados, compuestos y representados. Dos tipos:
Clase: usa herencia para variar la clase que es instanciada Objeto: delega instanciacin a otro objeto

Patrones de diseo

28

Patrones de Creacin
Se encapsula:
qu clases concretas usa el sistema cmo se crean las instancias de esas clases

El sistema conoce las clases abstractas Flexibilidad en qu se crea, quin lo crea, cmo se crea y cundo se crea.

Patrones de diseo

29

Ejemplo: Laberinto
<<abstract>> Sitio entrar()

Habitacion numero +lados entrar() getLado() setLado()

Muro entrar()

Puerta estaAbierta entrar()

Laberinto addHabitacion() numHabitacion()

30

public class JuegoLaberinto { public Laberinto MakeLaberinto () { Laberinto unLab = new Laberinto(); Habitacion h1 = new Habitacion(1); Habitacion h2 = new Habitacion(2); Puerta unaPuerta = new Puerta(1,2) unLab .addHabitacion (h1); unLab .addHabitacion (h2); h1.setLado(Norte, new Muro()); h1.setLado(Sur, new Muro()); h1.setLado(Este, new Muro()); h1.setLado(Oeste,unaPuerta); h2.setLado(Norte, new Muro); return unLab;} }

Ejemplo: Laberinto
Poco Flexible: diseo laberinto cableado Cmo crear laberintos con otros tipos de elementos como habitacionesEncantadas o puertasQueEscuchan? Patrones de creacin permiten eliminar referencias explcitas a clases concretas desde el cdigo que necesita crear instancias de esas clases.

Patrones de diseo

32

Abstract Factory (Factora Abstracta)

Propsito
Proporcionar una interfaz para crear familias de objetos relacionados o dependientes sin especificar la clase concreta

Motivacin
Un toolkit interfaz de usuario que soporta diferentes formatos: Windows, Motif, X-Windows,..

Patrones de diseo

33

Motivacin
WidgetFactory createScroolBar() CreateWindow()

Abstract Factory
Cliente

Window

MotifWidgetFactory createScroolBar() createWindow()

PMWidgetFactory createScroolBar() createWindow() PMWindow MotifWindow

ScrollBar

PMScroolBar

MotifScroolBar

Estructura
AbstractFactory CreateProductA() CreateProductB()

Abstract Factory
Cliente

AbstrProdA

ConcreteFactory1 createProductA() createProductB()

ConcreteFactory2 createProductA() createProdcutB() ProdA2 ProdA1

AbstrProdB

ProdB2

ProdB1

Abstract Factory
Aplicabilidad
Un sistema debera ser independiente de cmo sus productos son creados, compuestos y representados Un sistema debera ser configurado para una familia de productos. Una familia de objetos productos relacionados es diseada para ser utilizado juntos y se necesita forzar la restriccin. Se quiere proporcionar una librera de clases de productos y se quiere revelar slo la interfaz, no la implementacin.
Patrones de diseo 36

Abstract Factory
Consecuencias
Aisla a los clientes de las clases concretas de implementacin. Facilita el intercambio de familias de productos. Favorece la consistencia entre productos Es difcil soportar nuevas clases de productos.

Patrones de diseo

37

Abstract Factory
Implementacin
Factoras como singleton. Se necesita una subclase de AbstractFactory por cada clase de producto que redefine un mtodo factora.
Posibilidad de usar el patrn Prototype.

Definir factoras extensibles: AbstractFactory slo necesita un mtodo de creacin.

Patrones de diseo

38

Ejemplo: Laberinto
public class FactoriaLaberinto { public Laberinto makeLaberinto { return new Laberinto();} public Muro makeMuro {return new Muro();}; public Habitacion makeHabitacion(int n) { return new Habitacion(n); }; public Puerta makePuerta (Habitacion h1, Habitacion h2) {return new Puerta(h1,h2);} }

Patrones de diseo

39

public class JuegoLaberinto { public Laberinto makeLaberinto (FactoriaLaberinto factoria) { Laberinto unLab = factoria.makeLaberinto(); Habitacion h1 = factoria.makeHabitacion(1); Habitacion h2 = factoria.makeHabitacion(2); Puerta unaPuerta = factoria.makePuerta(h1,h2); unLab.addHabitacion(h1); unLab.addHabitacion(h2); h1.setLado(Norte, factoria.makeMuro()); h1.setLado(Este, unaPuerta) .. h2.setLado(Oeste, unaPuerta); h2.setLado(Sur, factoria.makeMuro()) return unLab; } }

Builder (Constructor)
Propsito
Separa la construccin de un objeto complejo de su representacin, as que el mismo proceso de construccin puede crear diferentes representaciones.

Motivacin
Un traductor de documentos RTF a otros formatos. Es posible aadir una nueva conversin sin modificar el traductor?

Patrones de diseo

41

Builder
Motivacin
RTFTraductor parseRTF() <<abstract>> ConversorTexto convertirCaracter() convertirCambioFont() ConvertirParrafo()

ASCIIConversor convertirCaracter() getTextoASCII()

ConversorTeX convertirCaracter() convertirCambioFont() convertirParrafo() getTextoTeX()

TextoASCII

TextoTeX

parseRTF { while (t = obtener siguiente token) { switch(t.tipo) { case Car: builder.convertirCaracter(t.char);break; case Font: builder.convertirCambioFont(t.font);break; case Par: builder.convertirParrafo(); break } } }

Builder
Estructura
Director Construir() +builder <<abstract>> Builder buildParte()

BuilderConcreto para todo objeto en estructura { builder.buildParte} Producto buildParte() getResultado()

44

Builder
Aplicabilidad
Cuando el algoritmo para crear un objeto complejo debe ser independiente de las piezas que conforman el objeto y de cmo se ensamblan. El proceso de construccin debe permitir diferentes representaciones para el objeto que se construye.

Patrones de diseo

45

Builder
Consecuencias
Permite cambiar la representacin interna del producto. Separa el cdigo para la representacin y para la construccin. Los clientes no necesitan conocer nada sobre la estructura interna. Diferentes directores pueden reutilizar un mismo builder Proporciona un control fino del proceso de construccin.
Patrones de diseo 46

Builder
Implementacin
La interfaz de Builder debe ser lo suficientemente general para permitir la construccin de productos para cualquier Builder concreto. La construccin puede ser ms complicada de aadir el nuevo token al producto en construccin. Los mtodos de Builder no son abstractos sino vacos. Las clases de los productos no tienen una clase abstracta comn.
Patrones de diseo 47

Ejemplo: Laberinto
public class BuilderLaberinto { public void buildLaberinto { }; public void buildPuerta { }; public void buildHabitacion(int n) { }; public Laberinto getLaberinto() { }; protected BuilderLaberinto() { }; }

Patrones de diseo

48

public class JuegoLaberinto { public Laberinto makeLaberinto (BuilderLaberinto builder) { builder.buildLaberinto(); builder.buildHabitacion(1); builder.buildHabitacion(2); builder.buildPuerta(1,2); return builder.getLaberinto(); } } class BuilderLaberintoNormal extends BuilderLaberinto { Laberinto labActual; // se define la construccin de un laberinto con determinado tipo de // puertas y habitaciones ... } Oculta la estructura interna

Factory Method (Mtodo Factora)

Propsito
Define un interfaz para crear un objeto, pero permite a las subclases decidir la clase a instanciar: instanciacin diferida a las subclases.

Motivacin
Una clase C cliente de una clase abstracta A necesita crear instancias de subclases de A que no conoce. En un framework para aplicaciones que pueden presentar al usuario documentos de distinto tipo: Clases Aplicacin y Documento. Se conoce cundo crear un documento, no se conoce de qu tipo.
Patrones de diseo 50

Factory Method
Motivacin
<<abstract>> Documento open() close() save() revert() <<abstract>> Aplicacion crearDocumento() nuevoDocumento() openDocumento() Documento d d = crearDocumento(); setDoc.add(d); d.open()

mtodo factoria
MiAplicacion MiDocumento crearDocumento()

return new MiDocumento

51

Factory Method
Estructura
<<abstract> Productos <<abstract>> Creador metodoFactoria() unaOperacion() prod = metodofactoria()

ProductoConcreto

CreadorConcreto metodoFactoria()

return new ProductoConcreto()

52

Factory Method
Aplicabilidad
Una clase no puede anticipar la clase de objetos que debe crear. Una clase desea que sus subclases especifiquen los objetos que debe crear. Una clase delega responsabilidad a una entre varias sublcases clases accesorias (helper) y se quiere localizar el conocimiento de en qu subclase helper se delega.

Patrones de diseo

53

Factory Method
Consecuencias
Evita ligar un cdigo a clases especficas de la aplicacin. Puede suceder que las subclases de Creador slo se crean con el fin de la creacin de objetos. Mayor flexibilidad en la creacin: subclases ofreciendo versiones extendidas de un objeto. El mtodo factora puede ser invocado por un cliente, no slo por la clase Creador: jerarquas paralelas

Patrones de diseo

54

Factory Method
<<abstract>> Figura crearManipulador() <<abstract>> Manipulador Cliente downClick() drag() upClick()

Linea crearManipulador()

Circulo crearManipulador()

ManipuladorLinea

ManipuladorCirculo

Patrones de diseo

55

Factory Method Implementacin

Dos posibilidades
Creador es una clase abstracta con un mtodo factora abstracto. Creador es una clase concreta que ofrece una implementacin por defecto del mtodo factora.

El mtodo factora puede tener un parmetro que identifica a la clase del objeto a crear. Se evita crear subclases de Creador con:
Metaclases (Smalltalk y Java) Genericidad (C++)
56

Factora y Metaclases
Cliente Factoria crear(tipo : String) : Producto

Producto return (Producto) Class.forName(tipo).newInstance()

P1

P2

57

Ejemplo: Laberinto
public class JuegoLaberinto { public Laberinto nuevoLaberinto () {...}; public Laberinto crearLaberinto() {return new Laberinto();}; public Habitacion crearHabitacion(int n) {return new Habitacion(n);}; public Muro crearMuro() {return new Muro();}; public Puerta crearPuerta(Habitacion h1, Habitacion h2) {return new Puerta(h1,h2);}; }

Patrones de diseo

58

public Laberinto nuevoLaberinto () { Laberinto unLab = crearLaberinto(); Habitacion h1 = crearHabitacion(1); Habitacion h2 = crearHabitacion(2); Puerta unaPuerta = crearPuerta(h1,h2); unLab.addHabitacion(h1); unLab.addHabitacion(h2); h1.setLado(Norte, crearMuro); h1.setLado(Este, unaPuerta) .. h2.setLado(Oeste, unaPuerta); h2.setLado(Sur, crearMuro) return unLab; } }

Prototype (Prototipo)
Propsito
Especificar los tipos de objetos a crear utilizando una instancia prototpica, y crear nuevas instancias mediante copias del prototipo.

Motivacin
GraphicTool es una clase de un framework que permite crear editores grficos, que crea objetos grficos, instancias de subclases de Graphic y los aade a un documento, cmo puede hacerlo si no sabe qu objetos grficos debe crear?
Patrones de diseo 60

Prototype
Motivacin
<<abstract>> Tool manipular() <<abstract>> Graphic dibujar() clone()

GraphicTool manipular()

+prototipo

Pentagrama dibujar() clone()

NotaMusical

Entera dibujar() clone()

Media dibujar() clone()

p = prototipo.clone(); while (usuario arrastra mouse) { p.draw(nuevapos) } insertar p in dibujo

return copy of self

Prototype
Estructura
Cliente
(from FactoryMethod)

+prototipo

<<abstract>> Prototipo clone()

operacion()

PrototipoConcr1 clone() p = prototipo.clone()

PrototipoConcr2 clone()

return copia de self

Prototype
Aplicabilidad
Cuando un sistema deba ser independiente de cmo sus productos son creados, compuestos y representados y:
las clases a instanciar son especificadas en tiempo de ejecucin. para evitar crear una jerarqua de factoras paralela a la de productos. cuando las instancias de una clase slo pueden encontrarse en uno de un pequeo grupo de estados. Inicializar un objeto es costoso

Patrones de diseo

63

Prototype
Consecuencias
Al igual que con Builder y Factory Abstract oculta al cliente las clases producto concretas. Es posible aadir y eliminar productos en tiempo de ejecucin: mayor flexibilidad que los anteriores. La composicin reduce el nmero de clases que es necesario crear. Un objeto prototipo puede estar formado por otros primitivos. Reduce la necesidad de crear subclases. Posibilidad de usar clases cargadas dinmicamente.
64

Prototype
Implementacin
Importante en lenguajes que no soportan el concepto de metaclase, as en Smalltalk o Java es menos importante. Usar un manejador de prototipos que se encarga del mantenimiento de una tabla de prototipos. Implementar la operacin clone es lo ms complicado. A veces se requiere inicializar el objeto creado mediante copia: prototipo con operaciones set.

65

Ejemplo: Laberinto
public class FactoriaPrototipoLaberinto { factoriaPrototipoLaberinto (Laberinto l, Puerta p, Habitacion h, Muro m); {protoLab = l; protoPuerta = p; protoHab = h; protoMuro = m;} public Laberinto makeLaberinto() {return (Laberinto)protoLab.clone()}; public Muro makeMuro {return (Muro) protoMuro.clone() }; public Habitacion makeHabitacion(int n) { Habitacion h = (Habitacion) protoHab.clone(); h.initialize(n); return h;} public Puerta makePuerta (Habitacion h1, Habitacion h2) {Puerta p = (Puerta) protoPuerta.clone(); p.initialize(h1,h2); return p} }
Patrones de diseo 66

JuegoLaberinto juego; FactoriaPrototipoLaberinto LaberintoSimple = new FactoriaPrototipoLaberinto (new Laberinto, new Puerta, new Habitacion, new Muro); Laberinto unlab = juego. makeLaberinto(LaberintoSimple)

JuegoLaberinto juego; FactoriaPrototipoLaberinto otroLaberinto = new FactoriaPrototipoLaberinto (new Laberinto, new PuertaQueOye, new HabitacionEncantada, new Muro); Laberinto unlab = juego. makeLaberinto(otroLaberinto)

Factora Abstracta con Prototipo

// crea objetos de una jerarqua de productos class Factoria { private HashTable catalogo; public Producto getProducto(String s) { return (Producto) ((Producto) catalogo.get(s)).clone();} public Factoria (String familia) {inicializa el catalogo} ... }

68

Singleton
Propsito
Asegurar que una clase tiene una nica instancia y asegurar un acceso global

Motivacin
Una nica instancia de la clase que maneja las ventanas, o de un spooler de impresoras o de un sistema de ficheros o de una factora. La clase se encarga de asegurar que exista una nica instancia y de su acceso.

Patrones de diseo

69

Singleton
Estructura
Singleton unicaInstancia datoSingleton instancia() operacionSingleton() getSingleton()

return unicaInstancia

Singleton.instancia().operacionSingleton()
70

Singleton
Aplicabilidad
Debe existir una nica instancia de una clase, accesible globalmente.

Consecuencias
Acceso controlado a la nica instancia Evita usar variables globales Generalizar a un nmero variable de instancias La clase Singleton puede tener subclases.

Patrones de diseo

71

Singleton
Puede suceder que Singleton tenga subclases y el cliente desee asociar a UnicaInstancia un objeto de una de las subclases.
Anlisis de casos en instancia() Singleton maneja un registro de singleton

En Smalltalk con variables de clase instancia podemos conseguir que cada subclase tenga su propio singleton.

72

Singleton
Implementacin Java
public class Singleton { public static Singleton instancia() { if (unicaInstancia = = null) {unicaInstancia = new Singleton()}; return unicaInstancia}; protected Singleton(); private static Singleton unicaInstancia = null;

Implementacin Smalltalk
new self error: no se puede crear el objeto default -- mtodo de clase UnicaInstancia isNil ifTrue: [UnicaInstancia:= super new]. ^UnicaInstancia.

Patrones estructurales
Cmo clases y objetos se combinan para formar estructuras ms complejas. Patrones de clase
Usan herencia (p.e. Adapter)

Patrones de objeto
Describen formas de combinar objetos para obtener nueva funcionalidad Posibilidad de cambiar la composicin en tiempo de ejecucin. Ej.: Composite, Proxy
Patrones de diseo 74

Adapter / Wrapper (Adaptador)

Propsito
Convertir la interfaz de una clase en otra que el cliente espera. Permite la colaboracin de ciertas clases a pesar de tener interfaces incompatibles

Motivacin
Un editor grfico incluye una jerarqua que modela elementos grficos (lneas, polgonos, texto,..) y se desea reutilizar una clase existente TextView para implementar la clase que representa elementos de texto, pero que tiene una interfaz incompatible.
Patrones de diseo 75

Adapter / Wrapper (Adaptador)

ElementoGrafico Editor marco() crearManipulador() return text.getExtension ElemLinea marco() crearManipulador() ElemTexto marco() crearManipulador() +texto

Motivacin

return new ManipuladorTexto

*
TextView getExtension()

76

Estructura Adapter/Clase
Cliente Objetivo metodo1() Adaptado especificoMet1()

<<implementation>> Adaptador metodo1() especificoMet1 ( )

77

Estructura Adapter/Objeto
Cliente Objetivo metodo1() Adaptado especificoMet1()

Adaptador metodo1() +adaptado

adaptado. especificoMet1()

78

Adapter
Aplicabilidad
Se desea usar una clase existente y su interfaz no coincide con la que se necesita:
se quiere usar una clase que invoca a un mtodo a travs de una interfaz, pero quiere usarse con otra clase que no implementa la interfaz

Se desea crear una clase reutilizable que debe colaborar con clases no relacionadas o imprevistas. (slo adaptador-objeto) se necesita usar varias subclases y es incmodo adaptar su interfaz aplicando subclassing.

Patrones de diseo

79

Adapter
Consecuencias
Un adaptador-clase no funciona cuando queramos adaptar una clase y sus subclases. Un adaptador-clase puede redefinir comportamiento heredado de Adaptado. Un adaptador-clase no implica ninguna indireccin, slo introduce un objeto. Un adaptador-objeto permite adaptar una clase y sus subclases, pudiendo aadir funcionalidad a todos los adaptados a la vez. Para un adaptador-objeto es complicado redefinir comportamiento de Adaptado.
80

Adapter
Consecuencias
La funcionalidad de Adaptador depende de la similitud entre la interfaz de las clases Objetivo y Adaptado. Adaptores pluggable:
Clases que incorporan una adaptacin de interfaz Cmo podemos conseguir que una clase reutilizable pueda incorporarse en sistemas existentes que esperan interfaces diferentes a la de la clase? Ejemplo: Clase TreeDisplay para visualizar estructuras jerrquicas (widget), exige que los objetos a visualizar tengan una determinada interfaz, p.e. clase abstracta Tree?
81

Adapter
Implementacin
En C++, la clase Adaptador hereda en modo privado de Adaptado y en modo pblico de Objetivo. Tres posibles implementaciones de adaptadores plugabbles:
Con operaciones abstractas Con delegacin de objetos Adaptadores parametrizados

82

Adapter
Objetivo, Cliente
TreeDisplay getChildren(Node) CreateGraphicNode(Node) display() BuilTree(Node n)

getChildren(n); for each child { addGraphicNode(CreateGraphicNode(child)); buildTree(child) }

DirectoryTreeDisplay FileSystemEntity getChildren(Node) createGraphicNode(Node)

adaptado adaptador

Adapter
Cliente
TreeDisplay +delegate setDelegate(delegate) display() buildTree(Node n) TreeAccesorDelegate getChildren(TreeDisplay, Node) CreateGraphicNode(TreeDisplay, Node)

Objetivo

delegate.getChildren(this,n); for each children { addGraphicNode( delegate.createGraphicNode(this,child)); buildTree(child) }

DirectoryBrowser getChildren() CreateGraphicNode() createFile() deleteFile()

adaptador

adaptado

FileSystemEntity

Ejercicio
Supuesto el sistema de terminal de punto de venta, disea una solucin basada en los patrones vistos para que el sistema pueda soportar diferentes servicios externos de terceras partes para clculo de impuestos o autorizacin de pagos.

Patrones de diseo

85

Bridge / Handle
Propsito
Desacoplar una abstraccin de su implementacin, de modo que los dos puedan cambiar independientemente.

Motivacin
Clase que modela la abstraccin con subclases que la implementan de distintos modos. Herencia hace difcil reutilizar abstracciones e implementaciones de forma independiente
Si refinamos la abstraccin en una nueva subclase, est tendr tantas subclases como tena su superclase. El cdigo cliente es dependiente de la plataforma.
Patrones de diseo 86

Bridge / Handle
Motivacin
Implementacin de una abstraccin window portable en una librera GUI.
Window Window

X Window

PMWindow

X Window

PMWindow

IconWindow

PMIconWindow X IconWindow

Patrones de diseo

Bridge / Handle
Motivacin
Window mostrarTexto() mostrarRect() +imp

imp.devMostrarLinea() imp.devMostrarLinea() imp.devMostrarLinea() imp.devMostrarLinea()

WindowImp devMostrarTexto() devMostrarLinea()

IconWindow mostrarBorde()

TransientWindow mostrarCaja()

XWindowImp devMostrarTexto() devMostrarLinea()

PMWindow devMostrarLinea() devMostrarTexto()

mostrarRect() mostrarTexto()

mostrarRect() mostrarTexto()

XmostrarLinea()

XmostrarTexto()

Bridge / Handle
Abstraccion operacion() +imp imp.operacionImp Implementacion operacionImp()

AbstraccionRefinada

ImplemA operacionImp()

ImplemB operacionImp()

Estructura
89

Bridge
Aplicabilidad
Se quiere evitar una ligadura permanente entre una abstraccin y su implementacin, p.e. porque se quiere elegir en tiempo de ejecucin. Abstracciones e implementaciones son extensibles. Cambios en la implementacin de una abstraccin no deben afectar a los clientes (no recompilacin). Ocultar a los clientes la implementacin de la interfaz. Se tiene una proliferacin de clases, como suceda en la Motivacin.
Patrones de diseo 90

Bridge
Consecuencias
Un objeto puede cambiar su implementacin en t.e. Cambios en la implementacin no motivarn recompilaciones de la clase Abstraccin y sus clientes. Se mejora la extensibilidad Se ocultan detalles de implementacin a los clientes

Patrones de diseo

91

Bridge
Implementacin
Aunque exista una nica implementacin puede usarse el patrn para evitar que un cliente se vea afectado si cambia. Cmo, cundo y dnde se decide que implementacin usar?
Constructor de la clase Abstraccion Elegir una implementacin por defecto Delegar a otro objeto, p.e. un objeto factora

Se puede usar herencia mltiple para heredar de la abstraccin y de una implementacin concreta, pero se liga una interface a una implementacin de forma permanente.

Composite
Propsito
Componer objetos en estructuras jerrquicas para representar jerarquas parte/todo. Permite a los clientes manejar a los objetos primitivos y compuesto de forma uniforme.

Motivacin
Modelar figuras compuestas Modelar paquetes de valores (acciones, bonos,..)

Patrones de diseo

93

Composite
Motivacin
<<abstract>> Figura dibujar() add(Figura) remove(Figura) getHijo(int)

Linea dibujar()

Rectangulo dibujar()

FiguraCompuesta dibujar() add(Figura) remove(Figura) getHijo(int)

94

Composite
Estructura
<<abstract>> Componente Cliente operacion() add(Componente) remove(Componente) getHijo(int)

Hoja operacion()

Composite operacion() add(Componente) +hijos remove(Componente) getHijo(int)

95

Composite
Aplicabilidad
Se quiere representar jerarquas parte/todo Se quiere que los clientes ignoren la diferencia entre objetos compuestos y los objetos individuales que los forman.

Patrones de diseo

96

Composite
Consecuencias
Jerarqua con clases que modelan objetos primitivos y objetos compuestos, que permite composicin recursiva. Clientes pueden tratar objetos primitivos y compuestos de modo uniforme. Es fcil aadir nuevos tipos de componentes. No se puede confiar al sistema de tipos que asegure que un objeto compuesto slo contendr objetos de ciertas clases, necesidad de comprobaciones en tiempo de ejecucin.
Patrones de diseo 97

Composite
Implementacin
Referencias de componentes hijos a su padre puede ayudar a el recorrido y manejo de la estructura compuesta. Debe contener Componente operaciones que no tienen significado para sus subclases? Dnde colocamos las operaciones de aadir y eliminar hijos?
Compromiso entre seguridad y transparencia. Transparencia: clase Componente Seguridad: clase hijo

Puede ser necesario especificar un orden en los hijos. Uso de cach. Qu estructura de datos es la adecuada?

Decorator (Decorador)
Propsito
Asignar dinmicamente nuevas responsabilidades a un objeto. Alternativa ms flexible a crear subclases para extender la funcionalidad de una clase.

Motivacin
Algunas veces se desea aadir atributos o comportamiento adicional a un objeto concreto no a una clase. Ejemplo: bordes o scrolling a una ventana. Herencia no lo permite.

Patrones de diseo

99

Decorator (Decorador)
VisualComponente mostrar()

Motivacin

TextView mostrar()

Decorator componente.mostrar mostrar() +componente

ScrollDecorator posicionScroll mostrar() scrollTo()

BorderDecorator anchoBorde mostrar() mostrarBorde() super.mostrar; mostrarBorde

Decorator (Decorador)
unB orderD ecorator

Motivacin

unS crollD ecorator

unTextV iew

Decorator (Decorador)
Componente operacion()

Estructura

CompConcreto operacion()

Decorator operacion() +componente componente.operacion

DecoratorConcrA estadoAdicional operacion()

DecoratorConcrB estadoAdicional operacion() comportAdicional() super.operacion; comportAdicional

Decorator (Decorador)
Aplicabilidad
Aadir dinmicamente responsabilidades a objetos individuales de forma transparente, sin afectar a otros objetos. Responsabilidades de un objeto pueden ser eliminadas. Para evitar una explosin de clases que produce una jerarqua inmanejable.

Patrones de diseo

103

Decorator (Decorador)
Consecuencias
Ms flexible que la herencia: responsabilidades pueden aadirse y eliminarse en tiempo de ejecucin. Diferentes decoradores pueden ser conectados a un mismo objeto. Reduce el nmero de propiedades en las clases de la parte alta de la jerarqua. Es simple aadir nuevos decoradores de forma independiente a las clases que extienden. Un objeto decorador tiene diferente OID al del objeto que decora. Sistemas con muchos y pequeos objetos.

Decorator (Decorador)
Implementacin
La interfaz de un objeto decorador debe conformar con la interfaz del objeto que decora. Clases decorador deben heredar de una clase comn. Componentes y decoradores deben heredar de una clase comn que debe ser ligera en funcionalidad. Si la clase Componente no es ligera, es mejor usar el patrn Strategy que permite alterar o extender el comportamiento de un objeto. Un componente no sabe nada acerca de sus decoradores, con Strategy sucede lo contrario.
105

Decorator (Decorador)
Implementacin
El decorador enva los mensajes al componente que decora, pudiendo extender la operacin con nuevo comportamiento. Las clases que modelan los decoradores concretos pueden aadir responsabilidades a las que heredan de Decorator.

106

Facade / Fachada
Propsito
Proporciona una nica interface a un conjunto de interfaces de un subsistema. Define una interface de ms alto nivel que facilita el uso de un subsistema.

Motivacin
Reducir las dependencias entre subsistemas. Un entorno de programacin que ofrece una librera de clases que proporcionan acceso a su subsistema compilador: Scanner, Parser, ProgramNode, ByteCodeStream y ProgramNodeBuilder. Clase Compiler acta como fachada.
Patrones de diseo 107

Estructura Fachada

Facade / Fachada
Aplicabilidad
Proporcionar una interfaz simple a un subsistema. Hay muchas dependencias entre clientes y las clases que implementan una abstraccin. Se desea una arquitectura de varios niveles: una fachada define el punto de entrada para cada nivel subsistema.

Patrones de diseo

109

Facade / Fachada
Consecuencias
Una fachada ofrece los siguientes beneficios: 1) Facilita a los clientes el uso de un subsistema, al ocultar sus componentes. 2) Proporciona un acoplamiento dbil entre un subsistema y los clientes: cambios en los componentes no afectan a los clientes. 3) No se impide a los clientes el uso de las clases del subsistema si lo necesitan.

Patrones de diseo

110

Facade / Fachada
Implementacin
Es posible reducir el acoplamiento entre clientes y subsistema, definiendo la fachada como una clase abstracta con una subclase por cada implementacin del subsistema. La fachada no es la nica parte pblica de un subsistema, sino que es posible declarar clases individuales del subsistema como pblicas (paquetes en Java, name space en C++).

111

Flyweight
Propsito
Uso de la comparticin para soportar eficientemente un gran nmero de objetos de poco tamao

Motivacin
En una aplicacin editor de documentos, modelamos los caracteres mediante una clase? Un flyweight es un objeto compartido que puede ser utilizado en diferentes contextos simultneamente.
No hace asunciones sobre el contexto Estado intrnseco vs. Estado extrnseco

Patrones de diseo

112

Flyweight
Estado intrnseco se almacena en el flyweight y consiste de informacin que es independiente del contexto y se puede compartir. Estado extrnseco depende del contexto y por tanto no puede ser compartido. Objetos clientes son responsables de pasar el estado extrnseco al flyweight cuando lo necesita. Flyweight se usan para modelar conceptos o entidades que son muy abundantes para representarse con objetos, p.e. caracteres de un texto.
Patrones de diseo 113

Flyweight
Flyweight carcter de un texto:
estado intrnseco: cdigo del carcter estado extrnseco: informacin sobre posicin y estilo
Elemento mostrar(contexto) intersec(point, contexto)

Fila char c +hijos mostrar(contexto) intersec(point, contexto)

Caracter

Columna mostrar(contexto) intersec(point, contexto) +hijos

mostrar(contexto) intersec(point, contexto)

Flyweight
FlyweightFactory getFlyweight() <<abstract>> Flyweight operacion(estadoExt)

Estructura

Concreto Cliente estadoIntrinseco operacion(estadoExt)

ConcretoSinCompartir todoEstado operacion(estadoExt)

Flyweight
flyweight getFlyweight (key) { if (flyweight[key]) existe {return flyweight existente} else {crear nuevo flyweight; aadirlo al conjunto de flyweight; return el nuevo flyweight} }

Patrones de diseo

116

Flyweight
Aplicabilidad
Aplicarlo siempre que se cumplan las siguientes condiciones: 1) Una aplicacin utiliza un gran nmero de objetos. 2) El coste de almacenamiento es alto debido al excesivo nmero de objetos. 3) La mayor parte del estado de un objeto puede hacerse extrnseco. 4) Muchos grupos de objetos pueden reemplazarse por unos pocos objetos compartidos al separar el estado extrnseco. 5) La aplicacin no depende de la identidad de los objetos.
Patrones de diseo 117

Flyweight
Consecuencias
Puede introducir costes run-time debido a la necesidad de calcular y transferir el estado extrnseco. La ganancia en espacio depende de varios factores:
la reduccin en el nmero de instancias el tamao del estado intrnseco por objeto si el estado extrnseco es calculado o almacenado

Interesa un estado intrnseco calculado Se suele combinar con el Composite.

Patrones de diseo

118

Flyweight
Implementacin
La aplicabilidad depende de la facilidad de obtener el estado extrnseco. Idealmente debe poder calcularse a partir de una estructura de objetos que necesite poco espacio de memoria. Debido a que los flyweight son compartidos, no deberan ser instanciados directamente por los clientes: clase FlyweightFactory.

Patrones de diseo

119

Proxy
Propsito
Proporcionar un sustituto (surrogate) de un objeto para controlar el acceso a dicho objeto.

Motivacin
Diferir el coste de crear un objeto hasta que sea necesario usarlo: creacin bajo demanda. Un editor de documentos que incluyen objetos grficos. Cmo ocultamos que una imagen se crear cuando se necesite?: manejar el documento requiere conocer informacin sobre la imagen.
Patrones de diseo 120

Proxy
<<abstract>> Grafico EditorDocumentos dibujar() getExtension() store() load() if (image == null) {im age = loadIm age(nom breFich)} else {imagen. dibujar()} Imagen impImagen extension dibujar() getExtension() store() load() ProxyImagen nombreFich extension dibujar() getExtension() store() load() if (im agen == null) { return extension} else {imagen.getExtension}

Motivacin

+imagen

Proxy
Cliente
(from flyweight)

<<abstract>> Sujeto operacion()

Estructura

SujetoReal operacion() +sujeto

Proxy operacion()

sujeto.operacion()

122

Proxy
Aplicabilidad
Siempre que hay necesidad de referenciar a un objeto mediante una referencia ms rica que una referencia normal. Situaciones comunes; 1) Proxy acceso remoto (acceso a un objeto en otro espacio de direcciones) 2) Proxy virtual (crea objetos grandes sobre demanda) 3) Proxy para proteccin (controlar acceso a un objeto) 4) Referencia inteligente (smart reference)

Patrones de diseo

123

Proxy
Consecuencias
Introduce un nivel de indireccin para: 1) Un proxy remoto oculta el hecho que objetos residen en diferentes espacios de direcciones. 2) Un proxy virtual tales como crear o copiar un objeto bajo demanda. 3) Un proxy para proteccin o las referencias inteligentes permiten realizar tareas de control sobre los objetos accedidos.

Patrones de diseo

124

Proxy
Implementacin
Sobrecargar el operador de acceso a miembros (->) en C++. En Smalltalk, posibilidad de definir Proxy como una clase que hereda de nil (no comprende ningn mensaje) y redefinir doesNotUnderstand para redirigir los mensajes al objeto sujeto. Puede suceder que baste con definir una nica clase Proxy para todos los tipos de sujetos.

Patrones de diseo

125

Patrones de comportamiento
Relacionados con la asignacin de responsabilidades entre clases. Describen no solo patrones de clases y objetos, sino tambin patrones de colaboracin entre objetos. Caracterizan un flujo de control ms o menos complejo que ser transparente al que utilice el patrn. Patrones de clase: Template Method e Interpreter Patrones de objeto: Mediator, Observer,..

Patrones de diseo

126

Chain of Responsibility (Cadena de Responsabilidad)

Propsito
Evita acoplar el emisor de un mensaje a su receptor dndole a ms de un objeto la posibilidad de manejar la solicitud. Se define una cadena de objetos, de modo que un objeto pasa la solicitud al siguiente en la cadena hasta que uno la maneja.

Motivacin
Facilidad de ayuda sensible al contexto. El objeto que proporciona la ayuda no es conocido al objeto (p.e. Un Button) que inicia la solicitud de ayuda.
Patrones de diseo 127

Chain of Responsibility
+manejador ManejadorAyuda manejarAyuda()

Motivacin
manejador.manejarAyuda

Aplicacion1

Widget

Dialog

Button manejarAyuda() mostrarAyuda() if puedo manejar { mostrarAyuda() } else { super manejarAyuda() }

128

Chain of Responsibility
GuardarDialogo : Dialog printBoton : But ton printDialogo : Dialog OKBoton : But ton : Aplicacion

Patrones de diseo

129

Chain of Responsibility
Estructura

Cliente
(from FactoryMethod)

Manejador manejarSolicitud()

+sucesor

ManejadorConcr1 manejarSolicitud()

ManejadorConcr2 manejarSolicitud()

130

Chain of Responsibility
Aplicabilidad
Ms de un objeto puede manejar una solicitud, y el manejador no se conoce a priori. Se desea enviar una solicitud a uno entre varios objetos sin especificar explcitamente el receptor. El conjunto de objetos que puede manejar una solicitud puede ser especificado dinmicamente.

Patrones de diseo

131

Chain of Responsibility
Consecuencias
Reduce acoplamiento Proporciona flexibilidad al asignar responsabilidades No se garantiza el manejo de la solicitud

Patrones de diseo

132

Chain of Responsibility
Implementacin
Dos posibles formas de implementar la cadena
Definir nuevos enlaces (en Manejador) Usar enlaces existentes (p.e. un objeto composite) class ManejadorAyuda { public ManejadorAyuda (ManejadorAyuda s) {sucesor = s}; public void ManejarAyuda () {if sucesor != null { sucesor.manejarAyuda;};}; private ManejadorAyuda sucesor; }

Patrones de diseo

133

Chain of Responsibility
Implementacin
Qu sucede si tenemos diferentes tipos de solicitudes?
En Manejador un mtodo para cada solicitud En el caso de Java, una interfaz por solicitud En Manejador un nico mtodo con un parmetro que representa el tipo de solicitud, por ejemplo un String. En Manejador un nico mtodo que tiene un parmetro de una clase Solicitud que representa la solicitud.
Patrones de diseo 134

Recursion OO
Una variante del patrn es que un objeto de la cadena pueda realizar parte del trabajo antes de pasar la solicitud al siguiente objeto: Recursin OO En Recursin OO no se est interesado en la organizacin de la cadena de objetos, slo que una estructura puede recorrerse.

Patrones de diseo

135

Recursion OO
Persona >> = unaPersona ^self nombre = unaPersona nombre NombrePersona >> = unaPersona ^ (self nombre = unaPersona nombre) and: [self apellidos = unaPersona apellidos] String >> = aString ...

Patrones de diseo

136

Chain of Responsibility
Ejemplo 1: Java 1.0 AWT
Mecanismo de delegacin de eventos: Un evento es pasado al componente donde ocurre que puede manejarlo o lo pasa a su contenedor.

Ejemplo 2: Sistema de control de seguridad

Existen varios sensores que transmiten el estado a un ordenador central. La accin de un sensor depende del contexto que lo incluye (jearqua de reas o zonas de seguridad). Un sensor pasa el evento al agregado que lo icnluye.
Patrones de diseo 137

Command
Propsito
Encapsula un mensaje como un objeto, permitiendo parametrizar los clientes con diferentes solicitudes, aadir a una cola las solicitudes y soportar funcionalidad deshacer/rehacer (undo/redo)

Motivacin
Algunas veces es necesario enviar mensaje a un objeto sin conocer el selector del mensaje o el objeto receptor. Por ejemplo widgets (botones, mens,..) realizan una accin como respuesta a la interaccin del usuario, pero no se puede explicitar en su implementacin.
Patrones de diseo 138

Command
Aplicacion2 add(Document) Menu add(MenuItem) MenuItem +command clicked() Command ejecutar()

Cut command.execute() Document open() close() cut() copy() paste() execute()

Paste execute() +document

document.paste

Motivacin

139

Command
Cliente1 Invocador Command ejecutar()

Receptor accion()

CommandConcreto +receptor estado ejecutar()

receptor.accion()

Estructura
140

Command
r : Receptor : Client e co : Command 1. Command (r) : Invocador

2. regist rarCommand(co)

3. ejecutar() 3.1. accion()

Colaboracin
141

Command
Aplicabilidad
Parametrizar objetos por la accin a realizar (en lenguajes procedurales con funciones Callback: funcin que es registrada en el sistema para ser llamada ms tarde; en C++ se puede usar punteros a funciones). Especificar, aadir a un cola y ejecutar mensajes en diferentes instantes: un objeto Command tiene un tiempo de vida independiente de la solicitud original. Soportar facilidad undo/redo. Recuperacin de fallos. Modelar transacciones
Patrones de diseo 142

Command
Consecuencias
Desacopla el objeto que invoca la operacin del objeto que sabe cmo realizarla. Cada subclase CommandConcreto especifica un par receptor/accion, almacenando el receptor como un atributo e implementando el mtodo ejecutar. Objetos command pueden ser manipulados como cualquier otro objeto. Se pueden crear command compuestos (aplicando el patrn Composite). Es fcil aadir nuevos commands.

Patrones de diseo

143

Command
Implementacin
Cul debe ser la inteligencia de un command?
No delegar en nadie Encontrar dinmicamente el objeto receptor y delegar en l

Soportar undo/redo
Atributos para almacenar estado y argumentos de la operacin. Lista de objetos commands En la lista se colocan copias.

Patrones de diseo

144

Command
Implementacin
Un objeto Command es realmente un Adapter: Command plugabble. Podemos evitar la jerarqua de subclases de Command si no necesitamos la facilidad undo/redo. En Smalltalk,
self receptor perform: unSelector with: unArg

Es posible asociar a un command ms de una accin (evento en un widget).

Patrones de diseo

145

Command
Ejemplo 1: Comparar dos objetos utilizando cualquier
criterio de ordenacin: interface Comparator en Java public interface Comparator { int compare (Object o1, Object o2); } Un objeto Comparator puede pasado a una rutina de ordenacin o ser utilizado por una coleccin para mantener el orden de sus elementos.

Ejemplo 2: Interfaz Observer en el patrn Observer.

Patrones de diseo

146

Interpreter
Propsito
Dado un lenguaje, definir una representacin para su gramtica junto con un intrprete que utiliza la representacin para interpretar sentencias en dicho lenguaje.

Motivacin
Interpretar una expresin regular. Usa una clase para representar cada regla, los smbolos en la parte derecha son atributos. Usar si la gramtica es simple y la eficiencia no es importante.
Patrones de diseo 147

Interpreter
Estructura
Contexto

Cliente3

ExpresionAbstracta interpretar(Contexto)

ExpresionTerminal interpretar(Contexto)

ExpresionNoTerminal interpretar(Contexto)

Patrones de diseo

148

Iterator (Iterador)
Propsito
Proporciona una forma para acceder a los elementos de una estructura de datos sin exponer los detalles de la representacin.

Motivacin
Un objeto contenedor tal como una lista debe permitir una forma de recorrer sus elementos sin exponer su estructura interna. Debera permitir diferentes mtodos de recorrido Debera permitir recorridos concurrentes No queremos aadir esa funcionalidad a la interfaz de la coleccin 149

Iterator (Iterador)
Motivacin
Una clase Iterator define la interfaz para acceder a una estructura de datos (p.e. una lista). Iteradores externos vs. Iteradores internos. Iteradores externos: recorrido controlado por el cliente Iteradores internos: recorrido controlado por el iterador

150

Iterador Externo

ListIterator Lista +list count() append() remove() first() next() hasNext() item() index()

Patrones de diseo

151

Iterador Externo
List list = new List(); ... ListIterator iterator = new ListIterator(list); iterator.first(); while (!iterator.isDone()) { Object item = iterator.currentItem(); // cdigo para procesar item iterator.next(); } ...
Patrones de diseo 152

Iteradores Externos en Java

interface Iterator { boolean hasNext(); Object next(); void remove(); } Iterator it = lista.iterator(); while (it.hasNext()) { Object item = it.next(); // cdigo para procesar item }
Patrones de diseo 153

Iterador Externo Polimrfico

ListaAbstracta crearIterador() count() append() remove() Cliente

Iterator first() next() isDone() CurrentItem()

Lista

ListIterator

Patrones de diseo

154

Iterador Interno
<<abstract>> ListaAbstracta count() append() remove() <<abstract>> Iterator doAll() doIf() action() test()

<<abstract>> IteradorLista Lista action() test() doAll() doIf()

Cliente

IteradorConcreto action() test()

Iterador Interno
public void doIf() { iterator.first(); while (!iterator.isDone()) { Object item = iterator.currentItem(); if (test(item)) action(item) iterator.next(); } }

Patrones de diseo

156

Iterator
Consecuencias
Simplifica la interfaz de un contenedor al extraer los mtodos de recorrido Permite varios recorridos, concurrentes Soporta variantes en las tcnicas de recorrido

Patrones de diseo

157

Mediator
Propsito
Define un objeto que encapsula como interaccionan un conjunto de objetos. Favorece un bajo acoplamiento, liberando a los objetos de referenciarse unos a otros explcitamente, y permite variar la interaccin de manera independiente.

Motivacin
Muchas interconexiones entre objetos dificulta la reutilizacin y la especializacin del comportamiento. Ventana que incluye un conjunto de elementos grficos con dependencias entre ellos.
Patrones de diseo 158

Mediator
Motivacin
DialogDirector showDialog() createWidgets() widgetChanged(Widget) Widget +director (from Logical View) changed() director.WidgetChanged(this)

FontDialogDirector createWidgets() widgetChanged(Widget)

+list

ListBox getSelection()

EntryField setText()

+field

159

Mediator
Motivacin
:Cliente :FontDialogDirector showDialog widgetChanged :ListBox :EntryField

getSelection

setText

160

Mediator
<<abstract>> Mediator +mediator Colega

MediatorConcreto

ColegaConcr1

ColegaConcr2

Estructura
161

Mediator
Aplicabilidad
Un conjunto de objetos se comunica entre s de una forma bien definida, pero compleja. Las interdependencias son poco estructuradas y difciles de comprender. Reutilizar una clase es difcil porque tiene dependencias con muchas otras clases. Un comportamiento que es distribuido entre varias clases debera ser adaptable sin crear subclases.

Patrones de diseo

162

Mediator
Consecuencias
Evita crear subclases Desacopla a los colegas. Simplifica los protocolos entre las clases Abstrae el cmo cooperan los objetos Centraliza el control en el mediador: clase difcil de mantener

Patrones de diseo

163

Mediator
Implementacin
No hay necesidad de definir una clase abstracta Mediator si los colegas trabajan con un nico mediador. Los colegas deben comunicarse con el mediador cuando un evento de inters ocurre, varias posibilidades: patrn Observer interfaz de notificacin especializada en Mediator (Smalltalk-V): clase ViewManager

Patrones de diseo

164

Memento
Propsito
Captura y exterioriza el estado interno de un objeto, sin violar la encapsulacin, de modo que el objeto puede ser restaurado a este estado ms tarde.

Motivacin
Algunas veces es necesario registrar el estado interno de un objeto: mecanismos checkpoints y deshacer cambios que permiten probar operaciones o recuperacin de errores. Mecanismo de transacciones

Patrones de diseo

165

Memento
Creator estado setMemento(Memento) CrearMemento() Memento estado getEstado() setEstado()

+memento

Guardian

return new Memento(estado)

estado = m. getEstado

Estructura
166

Memento
: Guardian : Creador m : Memento

1. crearMemento() 1.1. new 1.2. setEstado()

2. setMemento(m)

2.1. getEstado()

Colaboracin
167

Memento
Aplicabilidad
Una parte del estado de un objeto debe ser guardado para que pueda ser restaurado ms tarde. Una interfaz para obtener el estado de un objeto podra romper la encapsulacin exponiendo detalles de implementacin.

Patrones de diseo

168

Memento
Consecuencias
Mantiene la encapsulacin Simplifica la clase Creador ya que no debe preocuparse de mantener las versiones del estado interno. Podra incurrir en un considerable gasto de memoria: encapsular y restaurar el estado no debe ser costoso. Puede ser difcil en algunos lenguajes asegurar que slo el Creador tenga acceso al estado del Memento.

Patrones de diseo

169

Memento
Implementacin
Memento tiene dos interfaces, una para los creadores y otra para el resto de clases: clase amiga (C++), exportacin selectiva (Eiffel). Un memento puede registrar cambio incremental sobre el estado del creador: cuando se usa el patrn Command para el mecanismo undo/redo.

Patrones de diseo

170

Observer / Publish-Subscribe
Propsito
Define una dependencia uno-a-muchos entre objetos, de modo que cuando cambia el estado de un objeto, todos sus dependientes automticamente son notificados y actualizados.

Motivacin
Cmo mantener la consistencia entre objetos relacionados, sin establecer un acoplamiento fuerte entre sus clases? Ejemplo: Separacin Modelo-Vista

Patrones de diseo

171

Motivacin
90 80 70 60 50 40 30 20 10 0 1er trim. 2do trim. 3er trim. 4to trim. Este Oeste Norte

2tr 4tr 1tr 3tr

Vistas

Modelo
t1=20 t2=25 t3=90 t4=20

Este Oeste Norte

1tr. 20 30 47

2tr. 25 38 47

3tr. 90 32 45

4tr. 20 32 45

Observer
Estructura
Subject subjectState Attach() Detach() Notify() +observers 1..1 1..* Observer Update()

for all o in observers {o->update()}

ConcreteSubject subjectState getState() setState() +subject

ConcreteObserver observerState update() observerState= subject->getState()

173

Observer
Colaboracin
: Otra 1. setEstado() 1.1. notify() 1.1.1. update() 1.1. 2. updat e() : Subject o1 : Observer o2 : Observer

174

Observer
Aplicabilidad
Cuando un cambio de estado en un objeto requiere cambios en otros objetos, y no sabe sobre cuntos objetos debe aplicarse el cambio. Cuando un objeto debe ser capaz de notificar algo a otros objetos, sin hacer asunciones sobre quines son estos objetos.

Patrones de diseo

175

Observer
Consecuencias
Permite modificar independientemente subjects y observers. Acoplamiento abstracto y mnimo entre Subject y Observer: puede reutilizarlos por separado observers pueden aadirse sin modificar el subject Subject no necesita conocer las clases concretas de Observers

Patrones de diseo

176

Observer
Consecuencias Soporte para comunicacin de tipo broadcast:
el subject no especifica al receptor concreto de la notificacin es posible aadir y eliminar observers en cualquier instante.

Actualizaciones inesperadas Interfaz de Observer simple requiere que los observers tengan que deducir el item cambiado
Patrones de diseo 177

Observer
Implementacin
Es posible que un observer est ligado a ms de un subject: la operacin update tendr como argumento el subject. Quin dispara la notificacin? Mtodos set en la clase Subject Clientes de la clase Subject Asegurarse de notificar siendo el estado de Subject consistente Cunta informacin sobre el cambio se le enva a los observers con la notificacin?
Modelo Push (Mucha) y Modelo Pull (Muy Poca)
Patrones de diseo 178

Observer
Implementacin
Al registrar un observer es posible asociarle el evento sobre el que quiere ser notificado attach(Observer obs, Evento interes); Cuando las relaciones de dependencia entre Subject y Observer son complicadas encapsular la semntica de actualizacin en una clase ManejadorCambio (Mediador). En Smalltalk, las interfaces de las clases Subject y Observer se definen en la clase Object.
Patrones de diseo 179

Observer en Java
public class Observable { private boolean changed = false; private Vector obs; public Observable() { obs = new Vector(); } public synchronized void addObserver (Observer o) {..} public synchronized void deleteObserver (Observer o) {..} public void notifyObservers (Object arg) {..} protected synchronized void setChanged() {..} protected synchronized void clearChanged() {..} public synchronized boolean hasChanged() {.. }
Patrones de diseo 180

Observer en Java

public interface Observer { void update (Observable o, Object arg); }

Argumento pasado al mtodo notifyObservers, puede indicar el tipo de cambio

Patrones de diseo

181

Observer en Java
Problema
Que la clase que deseamos que acte como Observable ya herede de otra clase: En Java no hay herencia mltiple!
Usar delegacin Una clase ConcreteSubject contendr a un objeto de una clase que heredar de Observable: implementa addObserver y deleteObserver e invoca a notifyObservers() Se delega el comportamiento que necesita ConcreteSubject al objeto Observable que contiene. Por qu una subclase de Observable?
Patrones de diseo 182

Modelo de Eventos de Java 1.1

Java 1.1 introdujo un nuevo modelo de eventos para GUI basado en el patrn Observer. Componentes GUI que pueden generar eventos son llamados fuentes de eventos (event sources). Objetos que desean ser notificados de eventos GUI son llamados oyentes de eventos (event listeners). Una fuente juega el papel de ConcreteSubject y un listener juega el papel de ConcreteObserver. Los listeners deben registrarse en las fuentes.

Patrones de diseo

183

Modelo de Eventos de Java 1.1

Un listener debe implementar una interfaz que proporciona los mtodos que deben ser llamados por la fuente cuando ocurre el evento. Hay 11 interfaces listener cada una apropiada para un diferente tipo de evento GUI:
ActionListener, ItemListener, KeyListener, MouseListener, WindowListener, ...

En algunos casos la interfaz listener incluye ms de un mtodo: Java proporciona adaptadores

Patrones de diseo

184

State (Estado)
Propsito
Permite a un objeto cambiar su comportamiento cuando cambia su estado. El objeto parece cambiar de clase.

Motivacin
Una conexin TCP puede encontrarse en uno de varios estados, y dependiendo del estado responder de un modo diferente a los mensajes de otros objetos para solicitudes tales como abrir, cerrar o establecer conexin.

Patrones de diseo

185

State
TCPConexion +state open() close() acknowledge() open() close() acknowledge() TCPState

TCPEstablished open() close() acknowledge()

TCPListen open() close() acknowledge()

TCPClosed open() close() acknowledge()

state.acknowledge()

Motivacin
186

State
Context solicitud() +state State operacion()

StateConcr1 operacion() state.operacion()

StateConcr2 operacion()

Estructura
187

State
Aplicabilidad
El comportamiento del objeto depende de su estado, y debe cambiar su comportamiento en tiempo de ejecucin dependiendo de su estado. Las operaciones tienen grandes estructuras CASE que dependen del estado del objeto, que es representado por uno o ms constantes de tipo enumerado.

Patrones de diseo

188

State
Consecuencias
Coloca todo el comportamiento asociado a un particular estado en una clase. Subclases vs. Sentencias CASE. Ayuda a evitar estados inconsistentes Transiciones de estado son ms explcitas. Incrementa el nmero de objetos Los objetos State pueden ser compartidos.

Patrones de diseo

189

State
Implementacin
Quin define las transiciones entre estados? Context o subclases estado. Una alternativa es definir tablas que representan la matriz de transiciones de estado: no es posible asociar acciones a los cambios de estado y ms difcil de comprender. Cundo son creados los objetos estado? Pueden crearse cuando se necesiten o con antelacin y que Context tenga una referencia a ellos.

Patrones de diseo

190

Strategy/Policy (Estrategia)
Propsito
Define una familia de algoritmos, encapsula cada uno, y permite intercambiarlos. Permite variar los algoritmos de forma independiente a los clientes que los usan

Motivacin
Existen muchos algoritmos para justificacin de texto, debe implementarlo el cliente que lo necesita?

Patrones de diseo

191

Strategy
Composicion recorrer() formato() +algoJustif Justificacion justificar()

JustificacionSimple justificar() algoJustif.justificar

JustificacionTeX justificar()

Motivacin
192

Strategy
Contexto InterfaceContexto() +estrategia Estrategia algoritmoInterface()

EstrategiaA algoritmoInterface()

EstrategiaB algoritmoInterface()

Estructura
193

Strategy
Aplicabilidad
Configurar una clase con uno de varios comportamientos posibles. Se necesitan diferentes variantes de un algoritmo. Una clase define muchos comportamientos que aparecen como sentencias CASE en sus mtodos.

Patrones de diseo

194

Strategy
Consecuencias
Define una familia de algoritmos relacionados. Una alternativa a crear subclases de la clase Contexto. Elimina sentencias CASE El cliente puede elegir entre diferentes estrategias o implementaciones: debe conocer detalles Se incrementa el nmero de objetos: usar Flyweight State y Strategy son similares, cambia el Propsito: ejemplos de composicin con delegacin

Patrones de diseo

195

Strategy
Implementacin
Cmo una estrategia concreta accede a los datos del contexto? Pasar datos como argumentos Pasar el contexto como argumento Estrategia almacena una referencia al contexto

Patrones de diseo

196

Template Method (Mtodo Plantilla)

Propsito
Define el esqueleto (esquema, patrn) de un algoritmo en una operacin, difiriendo algunos pasos a las subclases. Permite a las subclases redefinir ciertos pasos de un algoritmo sin cambiar la estructura del algoritmo.

Motivacin
Fundamental para escribir cdigo en un framework. Clase Aplicacin que maneja objetos de la clase Documento: mtodo OpenDocument

Patrones de diseo

197

Template Method
void openDocument (String name) { if (! canOpenDocument(nombre){return}; Document doc = openDocument(); if !(doc = null) { docs. addDocument(doc); aboutToOpenDocument (doc); doc.open; doc.read(); } }
Patrones de diseo 198

Template Method
has(v:G): Boolean is do from start until after or else equal(v,item) loop forth end Result := not after end

Patrones de diseo

199

Template Method
Aplicabilidad
Implementar las partes fijas de un algoritmo y dejar que las subclases implementen el comportamiento que puede variar. Cuando el comportamiento comn entre varias subclases debe ser factorizado y localizado en una superclase comn. Controlar extensiones de las subclases: algoritmos con puntos de extensin

Patrones de diseo

200

Template Method
Consecuencias
Tcnica fundamental para la reutilizacin: factorizar comportamiento comn en libreras de clases Estructura de control invertida conocida como Principio de Hollywood: No nos llames, nosotros te llamaremos. Un mtodo plantilla (template) invoca a los siguientes tipos de mtodos:
operaciones concretas en la subclase concreta o en clientes operaciones concretas en la clase abstracta operaciones abstractas (primitivas) mtodos factora mtodos hook que proporcionan comportamiento por defecto
Patrones de diseo 201

Template Method
Implementacin
Minimizar el nmero de mtodos que es necesario redefinir en las subclases. Nombrar a los mtodos que se deben redefinir aadindole cierto prefijo, p.e. do. En C++, mtodos a redefinir son protegidos y virtuales, el mtodo plantilla no ser virtual.

Patrones de diseo

202

Visitor
Propsito
Representa una operacin que debe ser aplicada sobre los elementos de una estructura de objetos. Permite definir una nueva operacin sin cambiar las clases de los elementos sobre los que opera.

Motivacin
Un compilador que representa los programas como rboles de derivacin de la sintaxis abstracta necesita aplicar diferentes operaciones sobre ellos: comprobacin de tipos, generacin de cdigo, listados cdigo fuente, reestructuracin de programas,...
Patrones de diseo 203

Visitor
Motivacin
Nodo comprobarTipo() generarCodigo() prettyPrint()

NodoVariableRef comprobarTipo() generarCodigo() prettyPrint()

NodoAsignacion comprobarTipo() generarCodigo() prettyPrint()

204

Visitor
Motivacin
Nodo aceptar(VisitorNodo v) Programa

NodoVariableRef aceptar(VisitorNodo v)

NodoAsignacion Aceptar(VisitorNodo v)

v.visitarVariableRef(this)

v.visitarAsignacion(this)

205

Visitor
Motivacin
VisitorNodo visitarAsignacion(NodoAsignacion) visitarVariableRef(NodoVariableRef)

VisitorComprobacionTipos visitarAsignacion(NodoAsignacion) visitarVariableRef(NodoVariableRef)

VisitorGeneracionrCodigo visitarAsignacion(NodoAsignacion) visitarVariableRef(NodoVariableRef)

206

Visitor
Aplicabilidad
Tenemos una jerarqua de clases que representan objetos de propsito general (p.e. nodos de un rbol de derivacin de sintaxis) y podemos utilizarlo en diferentes aplicaciones, lo que implicara aadir mtodos en las clases de la jerarqua. Una estructura de objetos contiene muchas clases de objetos con diferentes interfaces, y se quiere realizar operaciones sobre los objetos que dependen de las clases concretas. Las clases definiendo la estructura de objetos cambian con poca frecuencia, pero a menudo se definen nuevas operaciones sobre la estructura. Mejor definir las operaciones en clases aparte.
Patrones de diseo 207

Visitor
Consecuencias
Facilidad para aadir nuevas operaciones: en vez de distribuir la funcionalidad, se aade un nuevo visitor. Un visitor recoge comportamiento relacionado, lo que simplifica las clases de los elementos. Es difcil aadir nuevas subclases de elementos concretos, ya que implica cambiar la jerarqua de Visitor. A diferencia de un iterador, Visitor puede visitar objetos de clases que no tienen una superclase comn. Compromete la encapsulacin: los elementos concretos deben permitir a los visitors hacer su trabajo.
Patrones de diseo 208

Visitor
Implementacin
El patrn permite aadir operaciones a clases sin cambiarlas. Esto se consigue aplicando la tcnica doubledispatch. Quin es responsable del recorrido de la estructura de objetos? Estructura de objetos Un iterador El visitor

Patrones de diseo

209

Double-Dispatch
Point>> + delta ^delta isPoint ifTrue:[(x+delta x) @ (y + delta y)] ifFalse:[(x+delta) @ (y + delta)] Point>> + delta ^delta addPoint: self Number>> addPoint: aPoint ^(self + aPoint x) @ (self + aPoint y) Point>> addPoint: aPoint ^(self x + aPoint x) @ (self y + aPoint y)

Patrones de diseo

210