Patrones de Diseño Introducción
Anuncio
Ingeniería del software II - CPS - Unizar
Patrones de Diseño
●
●
●
●
●
Introducción
Proxy pattern
Mediator pattern
Observer pattern
Factory pattern
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
1
Introducción
●
Objetivo
●
●
Consecuencias
●
●
Conseguir diseños reusables
ahorro de tiempo, toma de decisiones de diseño
automática, ...
¿Pero realmente se reutiliza la experiencia de
diseño o se reinventan las soluciones?
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
2
1
Ingeniería del software II - CPS - Unizar
Patrones de diseño
●
Objetivo
●
●
●
●
●
Guardar experiencias de diseño OO
Nombrar, evaluar y explicar diseños importantes que se repiten
en los sistemas OO
Ayudar a escoger alternativas de diseño (las que hacen los
sistemas reusables y evitar las que no)
Mejorar la documentación y el mantenimiento (facilitan la
especificación de las clases y las interacciones entre objetos)
Conclusión
●
Los patrones de diseño ayudan a diseñar más rápido
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
3
¿Qué es un patrón de diseño?
●
●
“Un patrón describe un problema que ocurre
una y otra vez en nuestro entorno y describe
el núcleo de la solución al problema, de
forma que puedes utilizar esta solución
millones de veces” [C. Alexander]
“Descripciones de clases y objetos que se
comunican y que son adaptadas para
resolver un problema de diseño general en
un contexto particular”
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
4
2
Ingeniería del software II - CPS - Unizar
¿Cómo se describe un patrón de
diseño?
●
Nombre y Clasificación
●
Propósito
●
Otros nombres
●
Motivación
●
●
Ejemplo real y cómo las clases y objetos del patrón lo
resuelven.
Aplicaciones
●
Cómo identificar situaciones donde utilizarlo.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
5
… ¿Cómo se describe un patrón
de diseño?
●
Estructura
●
●
Participantes
●
●
Diagrama de clases y traza de eventos (OMT
aumentado).
Lista de clases y objetos que participan con sus
responsabilidades.
Colaboraciones
●
Cómo colaboran los objetos para llevar a cabo sus
responsabilidades.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
6
3
Ingeniería del software II - CPS - Unizar
… ¿Cómo se describe un patrón
de diseño?
●
Consecuencias
●
●
Implementación
●
●
Ventajas y desventajas al usar el patrón
Técnicas y trucos a tener en cuenta cuando se
implementa el patrón (C++, Smalltalk)
Código de ejemplo
●
Fragmentos de código en C++ y Smalltalk
●
Usos conocidos
●
Patrones relacionados
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
7
Catálogo
●
●
●
Todos ellos son patrones ya probados y
utilizados en diferentes sistemas.
Forman parte del “folclore” de la
comunidad OO.
No pertenecen a ningún dominio
específico, resuelven problemas de
diseño genéricos (iterator, observer).
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
8
4
Ingeniería del software II - CPS - Unizar
Clasificación
●
Propósito
●
¿Qué hace el patrón?
Creación, Estructurales, Comportamiento.
●
●
Ambito
●
¿A quién se aplica el patrón?
Clase, Objeto
●
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
9
Bibliografía Recomendada
●
Design Patterns: Elements of Reusable ObjectOriented Software
Gamma E., Helm R., Johnson R., Vlissides J.
Addison-Wesley, 1995
ISBN: 0-201-63361-2
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
10
5
Ingeniería del software II - CPS - Unizar
Patrón: Proxy
Propósito
•
Otros nombres
•
Proporcionar un sustituto a otro objeto para controlarlo.
Sustituto (surrogate)
Motivación
•
Razón para controlar un objeto: Diferir el coste de su
creación e inicialización hasta que el objeto realmente se
necesite.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
11
Proxy: Motivación …
Ejemplo
•
•
•
•
Solución
•
Editor de documentos.
Utiliza objetos gráficos.
Abrir un documento debería ser rápido.
Realmente no todos los objetos son visibles a la vez.
Crear los objetos bajo demanda.
Pregunta
•
¿Qué ponemos en el documento en lugar de la imagen?
• No se complique la implementación, no tenga impacto en el
formato.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
12
6
Ingeniería del software II - CPS - Unizar
Proxy: Motivación …
• Solución
– Usar un objeto que sustituya a la imagen real Æ
PROXY.
– El proxy actúa como si fuese la imagen y la instancia
cuando es necesario.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
13
Proxy: Motivación …
Dos tipos de peticiones al editor:
•
•
Las que el proxy puede resolver por sí mismo.
Las que no (necesita instanciar al objeto real).
Para ello:
•
•
Las imágenes se almacenan en ficheros separados,
nombre del fichero es la referencia.
El proxy guarda el tamaño.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
14
7
Ingeniería del software II - CPS - Unizar
Proxy: Motivación …
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
15
Proxy: Aplicaciones
Donde exista la necesidad de referenciar un
objeto de forma más versátil y sofisticada
que un puntero.
•
•
•
“Proxy remoto” proporciona un representante local de un
objeto en un espacio de memoria diferente.
“Proxy virtual” para crear objetos de gran tamaño bajo
demanda.
“Proxy de protección” controla el acceso al objeto original.
Es útil si el objeto original tiene diferentes derechos de
acceso.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
16
8
Ingeniería del software II - CPS - Unizar
Proxy: Estructura
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
17
Proxy: Participantes
PROXY
•
•
•
•
Mantiene una referencia que le permite acceder al objeto
real.
Puede ser sustituido por el objeto real porque Subject
proporciona una interfaz idéntica.
Controla el acceso al objeto real y es responsable de su
creación y borrado.
Dependiendo del tipo de proxy:
• “proxy remoto”, responsable de enviar peticiones al espacio
de memoria del objeto real.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
18
9
Ingeniería del software II - CPS - Unizar
Proxy: Participantes (2)
• “proxy virtual”, debe almacenar información adicional sobre
el objeto real, para posponer su creación.
• “proxy de protección” debe chequear que el objeto que hace
la petición tiene los permisos requeridos.
SUBJECT
•
Define la interfaz común para el proxy y el objeto real.
REAL SUBJECT
•
Define el objeto real al que representa el proxy.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
19
Proxy: Colaboraciones y
Consecuencias
El proxy reenvía peticiones al objeto real
cuando lo considera conveniente.
El proxy introduce un nivel de indirección
cuando accede a un objeto. La indirección
tiene muchos usos dependiendo del tipo de
proxy:
•
•
•
Remoto: ocultar espacio de memoria.
Virtual: optimizaciones.
Protección: tareas adicionales.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
20
10
Ingeniería del software II - CPS - Unizar
Patrón: Mediator
Propósito
•
•
•
Definir un objeto que encapsula cómo
interacciona un conjunto de objetos.
Promueve un bajo acoplamiento evitando que
los objetos se comuniquen (interaccionen) entre
sí explícitamente.
Permitirá modificar las interacciones.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
21
Mediator: Motivación
Diseño OO hace hincapié en la distribución del
comportamiento del sistema entre los objetos.
Problema: en ciertos tipos de sistemas se puede
tener una estructura de objetos con muchas
conexiones. Al final todos los objetos terminan
conociéndose.
Reusabilidad:
•
•
•
Particionar un sistema en muchos objetos la facilita, pero
la proliferación de interconexiones entre ellos la reduce.
Gran cantidad de interconexiones hace difícil que un
objeto pueda trabajar sin la ayuda de otros. El sistema
actúa como si fuese monolítico.
Además puede resultar difícil cambiar el comportamiento
del sistema de forma significativa al estar distribuido entre
muchos objetos.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
22
11
Ingeniería del software II - CPS - Unizar
Mediator: Motivación …
Ejemplo
•
•
Implementación de un diálogo en una IGU.
Existen dependencias entre los elementos del diálogo:
• Seleccionar un elemento en la list box cambia el contenido
en otro campo.
Herencia
•
•
•
Diálogos diferentes (fuentes, imprimir) tendrán
dependencias diferentes entre sus elementos.
Incluso utilizando los mismos elementos, NO se pueden
reutilizar las clases.
Adaptar las clases para contemplar las dependencias
específicas del diálogo Æ Tedioso
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
23
Mediator: Motivación …
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
24
12
Ingeniería del software II - CPS - Unizar
Mediator: Motivación …
SOLUCION: Mediator
•
•
•
•
Encapsular el comportamiento colectivo en un objeto
mediador.
Será responsable de coordinar y controlar las
interacciones entre los objetos.
Será un intermediario que evitará a los objetos tener que
comunicarse directamente.
Los objetos conocerán únicamente al mediador, de esta
forma se reduce el número de interconexiones.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
25
Mediator: Motivación …
• Diagrama de objetos
– El mediador puede ser el mismo Diálogo.
– Conoce sus widgets y coordina sus interacciones. Actúa
como centro de comunicaciones.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
26
13
Ingeniería del software II - CPS - Unizar
Mediator: Motivación
• Traza de eventos
– Ilustra cómo cooperan los
objetos para manejar un
cambio en una selección de
la list box.
– El diálogo media entre la
list box y el entry field (se
comunican de forma
indirecta).
– Este comportamiento está
localizado en una clase,
puede ser cambiado
reemplazando la clase.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
27
Mediator: Motivación …
• Diagrama de clases
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
28
14
Ingeniería del software II - CPS - Unizar
Mediator: Aplicaciones
Utilizar el patrón cuando:
•
•
•
Un conjunto de objetos se comunican de
manera compleja pero bien definida. Las
comunicaciones no tienen estructura y son
difíciles de entender.
Reutilizar los objetos es difícil porque se
comunica con muchos otros.
El comportamiento está distribuido entre
muchas clases, debería ser adaptable sin mucha
herencia.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
29
Mediator: Estructura
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
30
15
Ingeniería del software II - CPS - Unizar
Mediator: Participantes
Mediator
•
ConcreteMediator
•
•
Define la interfaz para comunicar objetos colegas.
Implementa el comportamiento cooperativo coordinando
objetos colegas.
Conoce y mantiene a los colegas que dependen de él.
Clases Colleague
•
•
Cada clase colega conoce a su objeto mediador.
Cada colega comunica con su mediador cuando debería
comunicarse con otro colega.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
31
Mediator: Colaboraciones
Los colegas envían y reciben peticiones del
mediador.
El mediador implementa el comportamiento
cooperativo dirigiendo las peticiones a los colegas
apropiados.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
32
16
Ingeniería del software II - CPS - Unizar
Mediator: Consecuencias
Ventajas:
•
Limita la herencia.
• El mediador tiene comportamiento que de otra forma estaría
distribuido entre diferentes objetos.
• Cambiar este comportamiento implica únicamente
especializar el mediador.
• Las clases colegas pueden ser reutilizadas por otro mediador
y en otro sistema.
•
Desacopla a los colegas.
• El mediador hace que los colegas no estén acoplados. Se
pueden reutilizar independientemente las clases mediador y
colegas.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
33
Mediador: Consecuencias …
Ventajas …:
•
Simplifica los protocolos de los objetos.
• Reemplaza comunicaciones muchos a muchos por
comunicaciones uno a muchos que son más fáciles de
entender y mantener.
•
Abstrae cómo cooperan los objetos.
• Haciendo de la mediación un concepto independiente y
encapsulándola en un objeto permite concentrarte en
cómo interaccionan los objetos dejando aparte su
comportamiento individual.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
34
17
Ingeniería del software II - CPS - Unizar
Mediator: Consecuencias …
Desventajas:
•
Centraliza el control.
• Cambia la complejidad en las interacciones en los
objetos por complejidad en el objeto mediador.
• Como el mediador encapsula toda la comunicación
puede convertirse en algo monolítico y difícil de
mantener.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
35
Mediador: Implementación
Omitir la clase abstracta mediador.
•
•
Cuando las clases colega trabajan con un único mediador.
La clase abstracta mediador introduce un acoplamiento
abstracto que posibilita a los colegas usar diferentes
mediadores.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
36
18
Ingeniería del software II - CPS - Unizar
Patrón: Abstract Factory
Propósito
• Proporcionar un interfaz para crear familias de
objetos relacionados o dependientes sin especificar
sus clases concretas.
Otros nombres: Kit
Motivación: look-and-feel múltiple
• Contexto:
• Diseño de IGU en entornos basado en ventanas
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
37
Abstract Factory: Motivación
Objetivos
• Soportar múltiples estándares (MS-Windows, Motif,
Open Look, ...).
• Extensible para futuros estándares.
Restricciones
• Cambiar el look&feel sin recompilar.
• Cambiar el look&feel en tiempo de ejecución.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
38
19
Ingeniería del software II - CPS - Unizar
Abstract Factory: Motivación
Problema
• Creación de widgets en la aplicación cliente
Scrollbar *scrollbar = new MotifScrollBar();
Menu *menu = new MotifMenu();
• Las aplicaciones clientes NO deben crear sus
widgets para un look&feel concreto.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
39
Abstract Factory: Motivación
Solución
• Abstraer el proceso de creación de widgets.
• En lugar de
Scrollbar *sb = new MotifScrollBar();
• Usar
Scrollbar *sb= widgetFactory->CreateScrollBar();
• widgetFactory será una instancia de
MotifWidgetFactory o de MacWidgetFactory
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
40
20
Ingeniería del software II - CPS - Unizar
Abstract Factory: Motivación
Clase base AbstractFactory
• Define “interfaz para la creación”
• Sus subclases crean productos específicos
• Seleccionar factoría específica: tiempo de ejecución
class WidgetFactory{
public:
virtual Scrollbar * CreateScrollbar() = 0;
virtual Menu * CreateMenu() = 0;
...
protected:
WidgetFactory();
};
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
41
Abstract Factory: Motivación
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
42
21
Ingeniería del software II - CPS - Unizar
Abstract Factory: Aplicaciones
• Cuando un sistema debería funcionar de manera
independiente de cómo sus productos son creados,
compuestos y representados.
• Cuando un sistema debería ser configurado con
una de diferentes familias de productos.
• Cuando una familia de objetos se diseña para ser
usada en su conjunto.
• Si se quiere proporcionar una librería de clases de
productos, pero sólo se quiere desvelar las
interfaces, no las implementaciones.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
43
Abstract Factory: Estructura
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
44
22
Ingeniería del software II - CPS - Unizar
Abstract Factory: Consecuencias
Abstracción: el cliente manipula instancias a
través de interfaces abstractas. Los nombres
de productos no aparecen en el código
cliente.
Fomenta consistencia entre productos.
Puede ser difícil incorporar nuevos tipos de
productos. Cambiar AbstractFactory y sus
subclases.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
45
Abstract Factory: Código
class MazeFactory{
public:
MazeFactory();
virtual Maze* MakeMaze() = 0;
virtual Room* MakeRoom(int n) = 0;
...
};
Maze *MazeGame::CreateMaze(MazeFactory& factory){
Maze* aMaze = factory.MakeMaze();
Room* r1 = factory.MakeRoom(1);
Room* r2 = factory.MakeRoom(2);
aMaze->AddRoom(r1); aMaze->AddRoom(2);
...
}
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
46
23
Ingeniería del software II - CPS - Unizar
Abstract Factory: Código
class EnchantedMazeFactory: public MazeFactory{
public:
EnchantedMazeFactory();
virtual Room* MakeRoom(int n) const
{return new EnchantedRoom(n);}
...
};
class BombedMazeFactory: public MazeFactory{
public:
BombedMazeFactory();
virtual Room* MakeRoom(int n) const
{return new RoomWithABomb(n);}
...
};
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
47
Abstract Factory: Código
●
Crear un laberinto que puede tener bombas
MazeGame game;
BombedMazeFactory factory;
game.CreateMaze(factory);
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
48
24
Ingeniería del software II - CPS - Unizar
Patrón: Observer
Propósito:
•
Definir una dependencia 1 a muchos entre objetos de
modo que cuando un objeto cambia de estado, todos los
que de él dependen son notificados y actualizados
automáticamente.
Otros nombres:
•
Publish-Subscribe
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
49
Observer: Motivación
Efecto lateral de particionar un sistema en
clases Æ necesidad de mantener la
consistencia entre objetos relacionados.
Si hacemos clases fuertemente acopladas:
•
Consistencia
•
Reusabilidad
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
50
25
Ingeniería del software II - CPS - Unizar
Observer: Motivación …
• Ejemplo (hoja de cálculo):
– Separar los datos de la presentación.
– La hoja de cálculo y los gráficos muestran los
mismos datos con diferentes presentaciones.
– La hoja de cálculo y los gráficos no se conocen
entre sí.
– Reusar separadamente las clases de los datos de
las clases de presentación.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
51
Observer: Motivación
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
52
26
Ingeniería del software II - CPS - Unizar
Observer: Motivación …
Ejemplo …
•
•
•
No se conocen entre sí, pero se comportan
como si se conociesen: si el usuario cambia
datos en la hoja entonces se actualizan los
gráficos, y viceversa.
Los gráficos y la hoja dependen de los datos.
Deben ser notificados ante cualquier cambio en
los datos.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
53
Observer: Motivación …
Solución:
•
•
El patrón Observer describe cómo establecer las
relaciones.
Define:
• Subjects (sujetos): puede tener varios observadores.
• Observers (observadores): son notificados cuando un
subject sufre un cambio de estado. Preguntará al
subject por el nuevo estado para actualizarse.
• Los subjects publican notificaciones, los observers se
suscriben para recibir notificaciones.
• Las notificaciones se envían sin saber quién está
suscrito.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
54
27
Ingeniería del software II - CPS - Unizar
Observer: Aplicaciones
Usar el patrón cuando:
•
•
•
Cuando una abstracción tiene dos aspectos y uno
depende del otro. Encapsular los aspectos en objetos
diferentes para reusarlos.
Cuando cambiar un objeto implica cambiar otros y no
sabemos cuántos.
Cuando un objeto debe ser capaz de hacer notificaciones
a otros sin hacer asunciones de quienes son (bajo
acoplamiento).
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
55
Observer: Estructura
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
56
28
Ingeniería del software II - CPS - Unizar
Observer: Participantes
Subject:
•
•
Observer:
•
Interfaz para objetos que deben ser notificados.
ConcreteSubject:
•
•
Conoce sus observadores.
Proporciona métodos para suscribir y borrar observadores.
Almacena el estado que interesa a objetos ConcreteObserver.
Envía notificaciones a sus observadores cuando cambia su
estado.
ConcreteObserver:
•
•
•
Conoce a su subject concreto.
Almacena el estado que debe ser consistente con el del subject.
Implementa el Update().
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
57
Observer: Colaboraciones
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
58
29
Ingeniería del software II - CPS - Unizar
Observer: Consecuencias
Ventajas:
•
Acoplamiento mínimo entre subject y observer.
• Todo lo que sabe un subject es que tiene una lista de
observers que responden al interfaz observer.
• No conoce ninguna clase observer concreta.
•
Soporte para comunicación tipo broadcast.
• La notificación se extiende a todos los objetos de la lista.
• Se añaden y quitan observadores en cualquier momento.
• El observador hace lo que quiere con la notificación.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
59
Observer: Consecuencias …
Desventajas:
•
Coste de las actualizaciones.
• Un observer no conoce cuántos otros observers existen Æ no
conoce el coste de enviar un “cambio” al subject.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
60
30
Ingeniería del software II - CPS - Unizar
Observer: Implementación
Observar más de un subject.
•
•
Un observador puede depender de más de un subject.
Modificar Update(subject), así el observer sabe qué subject le ha
enviado el Update.
¿Quién dispara el Update()?
•
¿Qué objeto llama a Notify() para disparar Update()?
• (A) La solución expuesta:
Ventaja: el cliente no recuerda llamar a Notify().
Desventaja: ineficiencia cuando hay muchas operaciones
de cambio de estado continuas.
• (B) El observador:
Ventaja: eficiente. Evita cambios de estado intermedios
innecesarios.
Desventaja: errores. Si se olvida llamar a Notify().
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Prof. José Merseguer
61
Observer: Implementación …
Referencias a objetos borrados.
•
•
Quitar un subject NO debería dejar observadores
“colgados”.
Solución: el subject notifica a sus observadores que va a
ser borrado.
Modelos push & pull.
•
Pull.
• El subject envía la notificación, y los observadores preguntan
por los detalles (ineficiente).
•
Push.
• El subject envía información detallada sobre el cambio, tanto
si la quieren como si no (observadores menos reusables).
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Dr. José Merseguer
Prof. José Merseguer
62
31
