Post on 29-May-2020
Universidad de Valladolid
Departamento de Informática
Programación III I.T.I SistemasPatrones de diseño
Félix PrietoCurso 2004/05
Programación III I.T.I Sistemas Patrones 1
Motivación
Disponemos de las técnicas básicas de la Orientación aObjetos, sin embargo. . .
I Encontrar las clases es difícilI Estructurar bien las clases es más difícilI Hacerlo de forma reutilizable es más difícil aún
Necesitamos técnicas y estrategias que nos guien en laconstrucción de buenos sistemas Orientados a Objetos
I Ayudando a construir clasesI Ayudando a estructurar sistemas de clases
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 2
De�niciones
Cada patrón describe un problema que ocurre una y otravez en nuestro entorno y describe también el núcleo desu solución, de forma que puede utilizarse un millón deveces sin hacer dos veces lo mismo (ChristophAlexander, Arquitecto y urbanista)Un patrón de diseño es una descripción de clases yobjetos comunicándose entre si, adaptada para resolverun problema general de diseño en un contexto particular(GoF)Un patrón de diseño es una solución a un problema en uncontexto
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 3
Información sobre patrones de diseño
Jean-Marc Jézéquel, Michel Train, Christine MinginsDesign Patterns and contracts. Addison Wesley, 1999http://www.irisa.fr/prive/jezequel/DesignPatterns/
(GoF) Erich Gamma, Richard Helm, Ralph Johnson,John Vlissides Dessign Patterns. Elements of ReusableObject-Oriented Software Addison Wesley, 1995http://hillside.net/patterns/ (Patterns Home Page)http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html
(Introducción muy completa al tema.)
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 4
Qué no son los patrones de diseño
Patrones de diseño no es lo mismo queI Bibliotecas de clasesI FrameworksI Assets de grano gruesoI Técnicas y/o herramientas de refactorizaciónI Programación Extrema
También hay patrones de Análisis, de Arquitectura, deInterfaz de usuario, de diseño Web,... incluso hayAntiPatrones
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 5
Ventajas de los patrones de diseño
Facilitan la localización de los objetos que formarán elsistemaFacilitan la determinación de la granularidad adecuadaEspeci�can interfaces para las clasesEspeci�can implementaciones (al menos parciales)Facilitan el aprendizaje y la comunicación entreprogramadores
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 6
Clasi�cación
Respecto a su propósitoI Creacionales Resuelven problemas relativos a la creación
de objetosI Estructurales Resuelven problemas relativos a la
composición de objetosI de Comportamiento Resuelven problemas relativos a la
interacción entre objetosRespecto a su ámbito
I Clases Relaciones estáticas entre clasesI Objetos Relaciones dinámicas entre objetos
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 7
Los patrones del GoF
Clases Objetos
CreacionalMétodoFábrica
Fábrica Abstracta, Cons-tructor, Prototipo, Single-ton
Estructural AdaptadorAdaptador, Puente,Compuesto, Decorador,Fachada, Peso Mosca,Apoderado
Comportamiento
Intérprete,MétodoPlantilla
Cadena deResponsabilidad, Comando,Iterador, Mediador,Memento, Observador,Estado, Estrategia yVisitante
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 8
Plantilla general de descripción de un patrón
Nombre ¿Requiere explicación?Intención En dos líneas, qué hace, qué problema resuelve.Alias Otros nombres con que es conocidoMotivación Escenario de ejemploAplicabilidad Cuándo debe ser utilizado y cuándo no.Estructura Diagrama de clases de la solución propuesta.Participantes Diccionario de las clases que participan en la solu-
ción.Colaboraciones Relaciones que se establecen entre las clases an-
teriores.Consecuencias Ventajas e inconvenientes del uso de este patrón.Implementación Técnicas, trucos que se recomiendanPatr. relacionados Utilizados en éste, patrones que lo usan, alterna-
tivas,...
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 9
Adaptador (Adapter) (GoF p.131)
Intención: Convierte la interfaz de una clase en otrainterfaz esperada por los clientes. Permite lacooperación de clases que de otro modo seríanincompatiblesMotivación: Necesitamos reutilizar clases ajenas paranuestro sistema, pero, aunque la funcionalidad de estasclases es la que deseamos, la interfaz no es compatible.Si no podemos o no queremos modi�car las clases areutilizar, necesitamos hacerlas compatibles connuestro sistemaObservación: Este patrón tiene dos versiones, una conámbito en clases y otra con ámbito en objetos, peronosotros nos centraremos en la segunda versión
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 10
Adaptador (Adapter) (GoF p.131)
CLIENTE
OBJETIVO+peticion()
ADAPTADOR+peticion()
ADAPTABLE+peticion_incompatible()
mi_adaptado
mi_adaptado.peticion_incompatible()
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 11
Adaptador (Adapter) (GoF p.131)
ParticipantesI OBJETIVO: De�ne la interfaz que espera el clienteI ADAPTABLE: Implementa la interfaz incompatible que
necesitamos adaptarI ADAPTADOR: Implementa la interfaz de OBJETIVO
mediante llamadas al objeto adaptadoColaboraciones
I Los clientes utilizan la interfaz OBJETIVO. Suspeticiones son recogidas por un adaptador que lasredirige al objeto adaptado
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 12
Adaptador (Adapter) (GoF p.131)
ConsecuenciasI Un adaptador puede funcionar con varios adaptables de
forma simultanea, coordinando sus tareasI Si se necesita rede�nir el comportamiento deADAPTABLE basta construir un heredero y hacer que eladaptador lo adapte
I Introduce un nivel de indirección extra para satisfacerlas peticiones del cliente.
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 13
Compuesto (Composite) (GoF p.151)
Intención: Componer objetos en jerarquías todo-parte ypermitir a los clientes tratar objetos simples ycompuestos de manera uniformeMotivación: Necesitamos representar un conjunto deelementos de una interfaz grá�ca de usuario (GUI).Algunos de estos elementos son simples, mientras queotros están formados por varios elementos más simples.El comportamiento y/o la información que proporcionaun elemento complejo está determinada por loselementos que lo componen
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 14
Compuesto (Composite) (GoF p.151)
CLIENTE COMPONENTE+operacion()
HOJA+operacion()
COMPUESTO+operacion()+add()+remove()+iterar(): COMPONENTE
Para todo h hijo hacer h.operacion()
hijo *
*
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 15
Compuesto (Composite) (GoF p.151)Participantes
I COMPONENTE: Declara la intefaz común para todos losobjetos de la composición e implementa acciones pordefecto cuando sea apropiado. También puedeproporcionar la interfaz de acceso a hijos y padres
I SIMPLE: Representa los objetos simples e implementa sucomportamiento común
I COMPUESTO: Representa los objetos con hijos,almacenando a éstos e implementando las operaciones deacceso y mantenimiento relacionadas con ellos.
ColaboracionesI Los clientes utilizan la interfaz de COMPONENTEI Los objetos simples contestan directamente, mientras
que los compuestos pueden reenviar la operación a suscomponentes
I Los objetos que construyen la estructura deben serclientes tanto de SIMPLE como de COMPUESTO
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 16
Compuesto (Composite) (GoF p.151)
ConsecuenciasI Permite el tratamiento uniforme de objetos simples y
complejosI Simpli�ca el código de los clientes, que usan una sola
interfazI Permite añadir componentes nuevas sin afectar a los
clientesI Es difícil restringir los tipos de los hijosI De�nir las operaciones de gestión de los hijos enCOMPONENTE crea problemas de consistencia con loshijos
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 17
Comando (Command) (GoF p.215)
Intención: Encapsula una petición en un objeto. Permitecon ello parametrizar a los clientes con diferentespeticiones y almacenar peticiones para deshacerlas encaso necesarioMotivación: Parametrización de las acciones a realizarpor los objetos GUI de un framework (como hace eGTK)
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 18
Comando (Command) (GoF p.215)
CLIENTE
EMISOR
ORDEN+ejecutar()
RECEPTOR+accion()
ORDEN_CONCRETA+ejecutar()
*
mi_receptormi_receptor.accion()
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 19
Comando (Command) (GoF p.215)Participantes
I COMANDO: Declara la intefaz para ejecutar una operaciónI COMANDO_CONCRETO: De�ne una relación entre un
receptor y una acción, rede�niendo la operaciónejecutar para que se envíe una petición adecuada alreceptor
I CLIENTE: Crea un comando concreto indicándole cuál essu receptor
I EMISOR: Pide al comando que lleve a cabo una peticiónI RECEPTOR: Sabe cómo realizar la operación relacionada
con una peticiónColaboraciones
I El cliente crea un comando concreto indicándole cuál essu receptor
I El emisor almacena uno o varios comandos concretosI El emisor solicita al comando que se ejecuteI El comando pide al receptor que realice las operaciones
necesarias
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 20
Comando (Command) (GoF p.215)
:CLIENTE :COMANDO_CONCRETO :EMISOR :RECEPTOR
crea
almacena
ejecutar
accion
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 21
Comando (Command) (GoF p.215)
ConsecuenciasI La intermediación de comando desacopla emisor y
receptorI Permite manipular comandos tratados como objetosI Permite añadir nuevos comandos sin alterar las otras
clasesI Aplicando el patrón compuesto podemos obtener
comandos complejos (macros)I Los comandos pueden ser más o menos inteligentes
(solicitar un trabajo al receptor, o realizar tareas máscomplejas)
I Se puede adaptar la infraestructura para la opción«deshacer comando», ya sea de un nivel o de variosniveles (posiblemente eso requiera almacenar el estadoprevio del receptor)
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 22
Observador (Observer) (GoF p.269)
Intención: De�nir una dependencia entre un objeto y unconjunto de ellos, de modo que los cambios en el primerose vean re�ejados en los otrosMotivación: En un toolkit de GUI necesitamos separarlos objetos de presentación de los objetos que modelanlos datos interesantes para la aplicación, de forma quese puedan tener varias vistas sincronizadas de losmismos datos
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 23
Observador (Observer) (GoF p.269)
SUJETO inserta() quita() notifica()
OBSERVADOR actualiza()
SUJETO_CONCRETO estado cambia()
OBSERVADOR_CONCRETO estado_observador actualiza()
observador *
sujeto *
Para todo o Observador o.actualiza()
consulta el estadode su sujeto
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 24
Observador (Observer) (GoF p.269)
ParticipantesI SUJETO: Mantiene una lista de observadores y
proporciona una interfaz para su gestiónI OBSERVADOR: De�ne una interfaz para actualizar los
objetos que deben re�ejar los cambios en el sujetoI SUJETO_CONCRETO: Envía una noti�cación a sus
observadores cuando cambia su estadoI OBSERVADOR_CONCRETO: Mantiene una referencia a una
sujeto concreto, almacenando parte de su estado eimplementado la interfaz de OBSERVADOR
ColaboracionesI El SUJETO_CONCRETO noti�ca a sus observadores de los
cambios que sufreI Los observadores concretos solicitan a su sujeto los
datos necesarios para mantener la consistencia con sunuevo estado
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 25
Observador (Observer) (GoF p.269)
:OBSERVADOR_CONCRETO:SUJETO CONCRETO
:OBSERVADOR_CONCRETO
notifica()
cambia()
actualiza()
estado
actualiza()
estado
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 26
Observador (Observer) (GoF p.269)
ConsecuenciasI Permite reutilizar sujetos y observadores por separadoI Permite añadir nuevos observadores sin modi�car al
sujeto o a otros observadoresI Que el sujeto no informe a sus observadores de qué
cambio ha sufrido permite mantener el acoplamiento enun nivel bajo, puesto que el observador sólo pide losdatos del estado del sujeto que le interesan
I Aunque el observador no esté interesado en ciertoscambios del sujeto será noti�cado de ellos
I Se pueden realizar implementaciones con observadoresque coordinan información sobre varios sujetos
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 27
Iterador (Iterator) (GoF p.237)
Intención: Permite acceder secuencialmente a loselementos de un agregado sin exponer su estructurainternaMotivación: Necesitamos implementar una estructurade datos «compleja». Deseamos proteger a los clientesde la estructura frente a los detalles de implementaciónde la misma. permitiendo incluso que el cambio de suimplementación no afecte a los clientes.
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 28
Iterador (Iterator) (GoF p.237)
AGREGADO+crear_iterador()
CLIENTE
ITERADOR+primero()+siguiente()+fin()+actual()
AGREGADO_CONCRETO+crear_iterador()
ITERADOR_CONCRETO+primero()+siguiente()+fin()+actual()
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 29
Iterador (Iterator) (GoF p.237)
ParticipantesI ITERADOR: De�ne la interfaz común para recorrer todos
los agregados y acceder a ellosI AGREGADO: De�ne la interfaz de creación del iteradorI ITERADOR_CONCRETO: Implementa la interfaz deITERADOR y manteine la posición actual del iterador
I AGREGADO_CONCRETO: Implementa la interfaz decreación de los iteradores
ColaboracionesI El iterador concreto mantiene la información actualizada
sobre el recorrido que se está realizando sobre elagregado
Universidad de Valladolid Departamento de Informática c©�FÉLiX
Programación III I.T.I Sistemas Patrones 30
Iterador (Iterator) (GoF p.237)
ConsecuenciasI Podemos variar la forma de recorrer el agregado sin más
que cambiar el iterador. Varias formas diferentes derecorrido pueden ser encapsuladas en una jerarquía deiteradores
I La interfaz del agregado resulta más simple alimplementar menos operaciones de recorrido
I Permite el recorrido simultáneo con varios iteradores,utilizando varios algoritmos para el mismo.
I Hay muchas alternativas de implementación: Iteradorinterno o externo, cursor, iterador robusto,...
I La interfaz del iterador puede tener elementosadicionales (anterior, busca)
Universidad de Valladolid Departamento de Informática c©�FÉLiX