Este documento presenta una introducción a los patrones de diseño. Explica conceptos clave como qué es un patrón de diseño, cómo se describen y clasifican los patrones. Luego describe algunos patrones específicos como Abstract Factory y Singleton, explicando su propósito, motivación, estructura, participantes y colaboraciones. El documento provee una visión general de los patrones de diseño más comunes.

1. 1
Patrones de Diseño
(Design Patterns)

2. José Merseguer
Oscar Ansón
2
Patrones de Diseño
„ Introducción
„ Patrones de Creación
{ Abstract Factory
{ Singleton
„ Patrones de Estructuración
{ Composite
{ Proxy
„ Patrones de Comportamiento
{ Mediator
{ Observer
{ Strategy

3. José Merseguer
Oscar Ansón
3
Introducción
„ Objetivo del DOO
{ Conseguir diseños reusables y flexibles
„ Razón
{ Ahorro de tiempo
{ Ahorro de trabajo
{ Toma de decisiones de diseño automática
„ ¿Pero se reutiliza la experiencia en el
diseño o se reinventan las soluciones?

4. José Merseguer
Oscar Ansón
4
¿Qué es un Patrón de
Diseño?
„ “Un patrón de diseño describe un problema
que ocurre una y otra vez en nuestro
entorno y describe además el núcleo de la
solución a dicho problema, de esta forma se
puede usar dicha solución millones de
veces.” [C. Alexander]
„ Descripciones de objetos y clases que se
comunican y que son adaptadas para
resolver un problema de diseño general
dentro de un contexto particular.

5. José Merseguer
Oscar Ansón
5
¿Qué es un Patrón de
Diseño?
„ Un patrón de diseño tiene 4 elementos:
{ El Nombre
{ El Problema
{ La Solución
{ Las Consecuencias
„ Un patrón de diseño nombra, abstrae e
identifica los aspectos clave de una
estructura de diseño común, útil para crear
un diseño OO reusable.

6. José Merseguer
Oscar Ansón
6
¿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.

7. José Merseguer
Oscar Ansón
7
¿Cómo se describe un Patrón
de Diseño?
„ Estructura
{ Diagrama de clases y traza de eventos (en OMT
aumentado)
„ Participantes
{ Lista de clases y objetos que participan junto
con sus responsabilidades
„ Colaboraciones
{ Cómo colaboran los participantes para llevar a
cabo sus responsabilidades

8. José Merseguer
Oscar Ansón
8
¿Cómo se describe un Patrón
de Diseño?
„ Consecuencias
{ Ventajas y desventajas de usar el patrón
„ Implementación
{ Técnicas y trucos a tener en cuenta cuando se
implemente el patrón
„ Código fuente
{ Fragmentos de código fuente en C++ y
Smalltalk
„ Usos conocidos
„ Patrones relacionados

9. José Merseguer
Oscar Ansón
9
Catálogo de Patrones de
Diseño
„ 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).

10. José Merseguer
Oscar Ansón
10
Organización de los Patrones
de Diseño
„ Varían en:
{ Granularidad
{ Nivel de abstracción
„ Criterios de clasificación:
{ Propósito ¿Qué hace el patrón?
„ De Creación
„ De Estructuración
„ De Comportamiento
{ Ámbito ¿A quién se aplica el patrón?
„ Clase (estaticos)
„ Objeto (dinamicos)

11. José Merseguer
Oscar Ansón
11
Organización de los Patrones
de Diseño
„ Otras clasificaciones
{ Usos conjuntos
„ Composite y Visitor
{ Alternativas
„ Prototype y Abstract Factory
{ Similitud estructural
„ Composite y Decorator
{ Patrones relacionados

12. José Merseguer
Oscar Ansón
12
¿Cómo los Patrones de Diseño
resuelven problemas de diseño?
„ Ponen los mecanismos básicos de
reusabilidad a trabajar
{ Herencia Vs. Composición
{ Delegación
{ Herencia Vs. Tipos parametrizados
(templates)

13. José Merseguer
Oscar Ansón
13
¿Cómo seleccionar un Patrón
de Diseño?
„ Considerar cómo resuelven los problemas
de diseño
„ Revisar cuál es el propósito de cada patrón
„ Estudiar cómo se interrelacionan
„ Estudiar patrones con el mismo propósito
detectado
„ Detectar futuras causas de rediseño
„ Considerar qué variará en el diseño
propuesto

14. José Merseguer
Oscar Ansón
14
¿Cómo usar un Patrón de
Diseño?
„ Leer la descripción del patrón
„ Estudiar las secciones: estructura, participantes y
colaboraciones
„ Mirar la sección de código fuente
„ Elegir nombres para los participantes según el
contexto del problema
„ Definir las clases
„ Definir los nombres de las operaciones
„ Implementar las operaciones para asegurar las
responsabilidades y colaboraciones del patrón

15. José Merseguer
Oscar Ansón
15
¿Cómo usar un Patrón de
Diseño?
„ ¿Cómo NO usar un patrón?
{ Uso indiscriminado
„ El diseño se complica
„ Menor rendimiento
„ Revisar la sección “Consecuencias” de
cada patrón de diseño.

16. José Merseguer
Oscar Ansón
16
Bibliografía
„ Design Patterns: Elements of
Reusable Object-Oriented Software
{ Gamma E., Helm R., Johnson R.,
Vlissides J.
{ Addison-Wesley, 1995
{ ISBN: 0-201-63361-2

17. José Merseguer
Oscar Ansón
17
Patrones de Creación
„ Abstraen el proceso de instanciación
„ Hacen al sistema independiente de las
creaciones de objetos

18. José Merseguer
Oscar Ansón
18
Abstract Factory
„ Propósito
{ Proporcionar un interfaz para crear
familias de objetos relacionados o
dependientes sin especificar sus clases
concretas.
„ Otros nombres
{ Kit

19. José Merseguer
Oscar Ansón
19
Abstract Factory : Motivación
„ Look-and-Feel múltiple
{ Contexto: Diseño de GUI en entorno de
ventanas
„ Objetivos
{ Soportar múltiples estándares (MS-Windows,
Motif, Open Look, ...).
{ Extensible para futuros estándares.
„ Restricciones
{ Cambiar el Look-and-Feel sin recompilar.
{ Cambiar el Look-and-Feel en tiempo de
ejecución.

20. José Merseguer
Oscar Ansón
20
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-and-
Feel concreto.

21. José Merseguer
Oscar Ansón
21
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

22. José Merseguer
Oscar Ansón
22
Abstract Factory : Motivación
„ Clase base AbstractFactory
{ Define el “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();
};

23. José Merseguer
Oscar Ansón
23
Abstract Factory : Motivación

24. José Merseguer
Oscar Ansón
24
Abstract Factory : Aplicaciones
„ Usar cuando
{ Un sistema debe ser independiente de los
procesos de creación, composición y
representación de sus productos
{ Un sistema debe ser configurado con una
familia múltiple de productos
{ Una familia de productos relacionados se ha
diseñado para ser usados conjuntamente (y es
necesario reforzar esta restricción)
{ Se quiere proporcionar una librería de productos
y solo se quiere revelar sus interfaces

25. José Merseguer
Oscar Ansón
25
Abstract Factory : Estructura

26. José Merseguer
Oscar Ansón
26
Abstract Factory : Participantes
„ AbstractFactory (WidgetFactory)
{ Declara un interfaz para las operaciones de creación de
productos abstractos
„ ConcreteFactory (MotifWidgetFactory, PMWidgetFactory)
{ Implementa las operaciones de creación.
„ AbstractProduct (Window, ScrollBar)
{ Declara el interfaz para un tipo de productos.
„ ConcreteProduct (MotifWindow, MotifScrollBar)
{ Define el producto que creará la correspondiente concrete
factory.
{ Implementa el interfaz de AbstractProduct.
„ Client
{ Usa los interfaces declarados por las clases AbstractFactory and
AbstractProduct.

27. José Merseguer
Oscar Ansón
27
Abstract Factory : Colaboraciones
„ Una única instancia de cada
ConcreteFactory es creada en
tiempo de ejecución.
„ AbstractFactory delega la
creación de productos a sus subclases
ConcreteFactory

28. José Merseguer
Oscar Ansón
28
Abstract Factory : Consecuencias
„ Ventajas
{ Aisla las clases de implementación
„ Ayuda a controlar los objetos que se crean
„ Encapsula la responsabilidad de creación
{ Hace fácil el intercambio de familias de
productos
„ Cambio de factory -> Cambio de familia
{ Fomenta la consistencia entre productos
„ Desventajas
{ Puede ser difícil incorporar nuevos tipos de
productos (cambiar AbstractFactory y sus
factorias concretas)

29. José Merseguer
Oscar Ansón
29
Abstract Factory : Implementación
„ Factorias como singletons
{ Una instancia de ConcreteFactory por
familia de productos
„ Definir factorías extensibles
{ Añadiendo un parámetro en las
operaciones de creación que indique el
tipo de objeto a crear
„ Mas flexible
„ Menos seguro

30. José Merseguer
Oscar Ansón
30
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);
...
}

31. José Merseguer
Oscar Ansón
31
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);}
...
};

32. José Merseguer
Oscar Ansón
32
Abstract Factory : Código
„ Crear un laberinto que puede tener
bombas
MazeGame game;
BombedMazeFactory factory;
game.CreateMaze(factory);

33. José Merseguer
Oscar Ansón
33
Abstract Factory : Relacionados
„ Se pueden implementar con
{ Factory Method
{ Prototype
„ Las factorias concretas suelen ser
{ Singleton

34. José Merseguer
Oscar Ansón
34
Singleton
„ Propósito
{ Asegura una única instancia de una
clase y provee un punto de acceso global
a ella.

35. José Merseguer
Oscar Ansón
35
Singleton : Motivación
„ Necesidad en un SO de tener
exactamente
{ UNA ÚNICA cola de impresión
{ UN ÚNICO sistema de ficheros
{ …
{ Todos accesibles de forma global
„ Solución
{ Variable global

36. José Merseguer
Oscar Ansón
36
Singleton : Motivación
„ Problema
{ Sería complicado evitar instanciar más
de un objeto de esa clase
„ Solución
{ Usar Singleton
„ La propia clase se encargará de mantener
una única instancia y de hacerla accesible de
forma global a través de su interfaz

37. José Merseguer
Oscar Ansón
37
Singleton : Aplicaciones
„ Usar cuando
{ Deba haber una única instancia de la
clase y deba ser accedida desde un
punto conocido
{ La única instancia deba ser extensible
mediante herencia y los clientes deban
ser capaces de usar una instancia
extendida sin cambiar su código

38. José Merseguer
Oscar Ansón
38
Singleton : Estructura

39. José Merseguer
Oscar Ansón
39
Singleton : Participantes
„ Singleton
{ Define un método Instance() que
permite a los clientes acceder a la única
instancia
„ Instance() es un método de clase
(estático)
{ Podría ser la responsable de crear su
única instancia

40. José Merseguer
Oscar Ansón
40
Singleton : Colaboraciones
„ Los clientes acceden a la instancia
singleton únicamente a través del
método Instance()

41. José Merseguer
Oscar Ansón
41
Singleton : Consecuencias
„ Acceso controlado a una única
instancia
„ Reduce el espacio de nombres
„ Permite el refinamiento de
operaciones y representación
{ Heredando de ella
„ Permite un número variable de
instancias

42. José Merseguer
Oscar Ansón
42
Singleton : Implementación
„ Asegurar una única instancia
{ Ocultar la operación de creación detrás
de un método de clase
„ Heredar de una clase Singleton
{ Mediante un registro de singletons

43. José Merseguer
Oscar Ansón
43
Singleton : Código
class MazeFactory {
public:
static MazeFactory* Instance();
…
protected:
MazeFactory();
private:
static MazeFactory* _instance;
};
MazeFactory* MazeFactory::_instance = 0;
MazeFactory* MazeFactory::Instance () {
if (_instance == 0) {
_instance = new MazeFactory;
}
return _instance;
}

44. José Merseguer
Oscar Ansón
44
Singleton : Relacionados
„ Muchos patrones pueden
implementarse usando el patrón
Singleton
{ Abstract Factory
{ Builder
{ Prototype

45. José Merseguer
Oscar Ansón
45
Patrones de Estructuración
„ Determinan cómo se componen clases y
objetos para obtener nuevos sistemas
estructurales
„ Ámbito de clase
{ Ejemplo sencillo: herencia múltiple
„ Ámbito de objeto
{ Componen objetos para obtener una nueva
funcionalidad
{ Cambia en tiempo de ejecución

46. José Merseguer
Oscar Ansón
46
Composite
„ Propósito
{ Compone objetos en estructuras de árbol
para representar jerarquías de tipo
“partes-todo”. Permite tratar objetos
individuales y composiciones de objetos
de forma uniforme.

47. José Merseguer
Oscar Ansón
47
Composite : Motivación
„ Aplicación de dibujo esquemático
„ Objetivos
{ Diferentes elementos de construcción (lineas,
rectángulos, círculos, etc).
{ El usuario puede agrupar elementos para
generar otros mas complejos
„ De forma recursiva
„ Solución
{ Clases para representar los elementos básicos
{ Clases para representar contenedores de esos
elementos

48. José Merseguer
Oscar Ansón
48
Composite : Motivación
„ Problema
{ Se tratan los objetos de dibujo y los
contenedores de forma diferente
„ Solución
{ El patrón Composite describe una
composición recursiva transparente a los
clientes.

49. José Merseguer
Oscar Ansón
49
Composite : Motivación

50. José Merseguer
Oscar Ansón
50
Composite : Motivación

51. José Merseguer
Oscar Ansón
51
Composite : Aplicaciones
„ Usar cuando
{ Se quiere representar jerarquías de
objetos del estilo “parte-todo”
{ Se quiera hacer transparente al cliente la
diferencia entre composiciones de
objetos y objetos individuales
„ Tratamiento uniforme de ambos

52. José Merseguer
Oscar Ansón
52
Composite : Estructura

53. José Merseguer
Oscar Ansón
53
Composite : Estructura

54. José Merseguer
Oscar Ansón
54
Composite : Participantes
„ Component (Graphic)
{ Declara el interfaz para los objetos en la composición.
{ Implementa el comportamiento por defecto del interfaz común a todas
las clases.
{ Declara un interfaz para acceder y manejar a los componentes hijos.
{ (optional) define un interfaz para acceder al componente padre.
„ Leaf (Rectangle, Line, Text, etc.)
{ Representa un objeto hoja en la composición. Una hoja no tiene hijos.
{ Define el comportamiento de las primitivas de la composición.
„ Composite (Picture)
{ Define el comportamiento de los componentes que tienen hijos.
{ Almacena los hijos.
{ Implementa las operaciones relacionadas con los hijos en el interfaz de
Component.
„ Client
{ Manipula los objetos de la composición a traves del interfaz de
Component.

55. José Merseguer
Oscar Ansón
55
Composite : Colaboraciones
„ Los clientes usan el interfaz de
Component para interactuar con los
objetos de la estructura compuesta.
{ Si el objeto es una Leaf, la petición la
maneja directamente.
{ Si el objeto es un Composite, la petición
se difunde a los hijos.

56. José Merseguer
Oscar Ansón
56
Composite : Consecuencias
„ Ventajas
{ Define jerarquías de objetos primitivos y objetos
compuestos.
{ Permite clientes más simples
„ no se deben preocupar si están tratando con un objeto
primitivo o uno compuesto
{ Es sencillo añadir nuevos componentes
„ Desventajas
{ Puede hacer el diseño demasiado general
„ Es difícil restringir los componentes de un Composite
(checkeos en tiempo de ejecución)

57. José Merseguer
Oscar Ansón
57
Composite : Implementación
„ Referencias explícitas a los padres
„ Compartir componentes
{ Reducción de espacio en memoria
„ “Caching” para mejorar el rendimiento
{ Evitando la delegación de operaciones a
los hijos

58. José Merseguer
Oscar Ansón
58
Composite : Código

59. José Merseguer
Oscar Ansón
59
Composite : Relacionados
„ Normalmente el link entre componente y padre se usa para
{ Chain of Responsibility
„ Se usa normalmente junto con
{ Decorator (Compartiendo la misma clase padre)
„ Para compartir componentes se usa
{ Flyweight
„ Para recorrer la jerarquía se puede usar
{ Iterator
„ Para confinar en un mismo sitio operaciones y
comportamiento que de otra forma quedaría distribuido en la
jerarquía se usa
{ Visitor

60. José Merseguer
Oscar Ansón
60
Proxy
„ Propósito
{ Proporciona un sustituto de otro objeto
con el fin de controlar su acceso.
„ Otros nombres
{ Surrogate (Sucedáneo/Sustituto)

61. José Merseguer
Oscar Ansón
61
Proxy : Motivación
„ Razón para controlar el acceso a un objeto: Diferir
el coste de su creación e inicialización hasta que el
objeto realmente se necesite.
„ Ejemplo
{ Editor de documentos que permite objetos gráficos
{ Abrir un documento debería ser rápido
{ Realmente, no todos los objetos son visibles a la vez
„ Solución
{ 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.

62. José Merseguer
Oscar Ansón
62
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.

63. José Merseguer
Oscar Ansón
63
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.

64. José Merseguer
Oscar Ansón
64
Proxy : Motivación

65. José Merseguer
Oscar Ansón
65
Proxy : Aplicaciones
„ Donde exista la necesidad de referenciar un objeto
de forma más versátil y sofisticada que un puntero.
{ Proxy remoto (Ambassador / Embajador)
„ 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.
{ Referencia elegante (smart pointers)
„ Realiza acciones adicionales cuando se acceden a los
elementos referenciados

66. José Merseguer
Oscar Ansón
66
Proxy : Estructura

67. José Merseguer
Oscar Ansón
67
Proxy : Participantes
„ Proxy
{ Mantiene un referencia al objeto real
{ Mantiene un mismo interfaz que el objeto real
{ Mantiene el acceso al objeto real
{ Codificación de peticiones, Caching de
información, comprobar permisos
„ Subject
{ Define el interfaz común a Proxy y RealSubject
„ RealSubject
{ Define el objeto real que representa el Proxy

68. José Merseguer
Oscar Ansón
68
Proxy : Colaboraciones
„ El Proxy reenvía peticiones al objeto
real (RealSubject) cuando lo
considera conveniente.

69. José Merseguer
Oscar Ansón
69
Proxy : Consecuencias
„ 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 & Smart Ptrs: tareas adicionales.
„ CoW: Copy-on-Write
{ Una forma de creación bajo demanda

70. José Merseguer
Oscar Ansón
70
Proxy : Implementación
„ Sobrecarga del operador operator->
„ El Proxy no tiene por qué saber
siempre el tipo de RealSubject

71. José Merseguer
Oscar Ansón
71
Proxy : Código

72. José Merseguer
Oscar Ansón
72
Proxy : Relacionados
„ Si ofrece un interfaz distinto (proxy de
seguridad)
{ Adapter
„ Tiene una implementación similar a
{ Decorator

73. José Merseguer
Oscar Ansón
73
Patrones de Comportamiento
„ Se centran en algoritmos y asignación
de responsabilidades entre objetos
„ No sólo determinan patrones de
clases y objetos, sino también
patrones de comunicación entre los
mismos

74. José Merseguer
Oscar Ansón
74
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 de
forma independiente a los objetos que
interactúan.

75. José Merseguer
Oscar Ansón
75
Mediator : Motivación
„ El 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.

76. José Merseguer
Oscar Ansón
76
Mediator : Motivación
„ Ejemplo
{ Implementación de un diálogo en una GUI.
{ Existen dependencias entre los elementos del diálogo:
„ Seleccionar un elemento en la list box cambia el contenido
en otro campo.
„ Problema
{ 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 mediante herencia para contemplar las
dependencias específicas del diálogo (Tedioso)

77. José Merseguer
Oscar Ansón
77
Mediator : Motivación

78. José Merseguer
Oscar Ansón
78
Mediator : Motivación
„ Solución
{ 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 con el
resto de objetos.
{ Los objetos conocerán únicamente al mediador,
de esta forma se reduce el número de
interconexiones.

79. José Merseguer
Oscar Ansón
79
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.

80. José Merseguer
Oscar Ansón
80
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.

81. José Merseguer
Oscar Ansón
81
Mediator : Motivación

82. José Merseguer
Oscar Ansón
82
Mediator : Aplicaciones
„ Usar 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 y debería ser adaptable sin
mucha herencia.

83. José Merseguer
Oscar Ansón
83
Mediator : Estructura

84. José Merseguer
Oscar Ansón
84
Mediator : Participantes
„ Mediator
{ Define la interfaz para comunicar objetos Colleage.
„ ConcreteMediator
{ Implementa el comportamiento cooperativo coordinando
objetos Colleage.
{ Conoce y mantiene a los Colleage que dependen de él.
„ Clases Colleage
{ Cada colega conoce a su objeto Mediator.
{ Cada colega se comunica con su Mediator siempre que
quiera comunicarse con otro colega.

85. José Merseguer
Oscar Ansón
85
Mediator : Colaboraciones
„ Los colegas envían y reciben
peticiones del mediador.
„ El mediador implementa el
comportamiento cooperativo dirigiendo
las peticiones a los colegas
apropiados.

86. José Merseguer
Oscar Ansón
86
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.

87. José Merseguer
Oscar Ansón
87
Mediator : 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 la cooperación entre los objetos.
„ Haciendo de la mediación un concepto independiente
y encapsulándola en un objeto permite concentrarse
en cómo interaccionan los objetos dejando aparte su
comportamiento individual.

88. José Merseguer
Oscar Ansón
88
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.

89. José Merseguer
Oscar Ansón
89
Mediator : 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.

90. José Merseguer
Oscar Ansón
90
Mediator : Código

91. José Merseguer
Oscar Ansón
91
Mediator : Relacionados
„ Los colegas pueden comunicarse con
el mediador mediante
{ Observer
„ Si se abstrae un subsistema de
objetos con protocolo unidireccional se
usa
{ Facade

92. José Merseguer
Oscar Ansón
92
Observer
„ Propósito
{ Definir una dependencia “uno 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
{ Dependents, Publish-Subscribe

93. José Merseguer
Oscar Ansón
93
Observer : Motivación
„ Efecto lateral de particionar un sistema
en clases que colaboran
{ necesidad de mantener la consistencia
entre objetos relacionados.
„ Si hacemos clases fuertemente
acopladas
{ MAS Consistencia
{ MENOS Reusabilidad

94. José Merseguer
Oscar Ansón
94
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.

95. José Merseguer
Oscar Ansón
95
Observer : Motivación

96. José Merseguer
Oscar Ansón
96
Observer : Motivación
„ Ejemplo (hoja de cálculo)
{ 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.

97. José Merseguer
Oscar Ansón
97
Observer : Motivación
„ Solución
{ El patrón Observer describe cómo establecer
las relaciones.
{ Define
„ Subjects (sujetos observados): 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.

98. José Merseguer
Oscar Ansón
98
Observer : Aplicaciones
„ Usar cuando
{ Una abstracción tiene dos aspectos, uno
dependiente del otro. Encapsulándolos en
objetos separados se permite variarlos y
reusarlos de forma independiente.
{ El cambio en un objeto implica cambiar otros y
no sabemos cuántos
{ Cuando un objeto debe ser capaz de hacer
notificaciones a otros sin hacer suposiciones de
quiénes son (queremos un bajo acoplamiento).

99. José Merseguer
Oscar Ansón
99
Observer : Estructura

100. José Merseguer
Oscar Ansón
100
Observer : Participantes
„ Subject
{ Conoce sus observadores.
{ Proporciona métodos para suscribir y borrar observadores.
„ Observer
{ Define el interfaz para objetos que deben ser notificados.
„ ConcreteSubject
{ 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 método Update().

101. José Merseguer
Oscar Ansón
101
Observer : Colaboraciones
„ ConcreteSubject notifica a sus
observadores siempre que se produce
un cambio
{ Evitando inconsistencia entre los estados
de los observadores y el subject.
„ Después de ser informado, un
ConcreteObserver puede pedir
información al Subject.

102. José Merseguer
Oscar Ansón
102
Observer : Colaboraciones

103. José Merseguer
Oscar Ansón
103
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.

104. José Merseguer
Oscar Ansón
104
Observer : Consecuencias
„ Desventajas
{ Coste de las actualizaciones.
„ Un observer no conoce cuántos observers
más existen y por lo tanto, no conoce el
coste de enviar un “cambio” al subject.
{ Podría producirse un Update en cascada.

105. José Merseguer
Oscar Ansón
105
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()?
{ El Subject (La solución expuesta):
„ Ventaja: El cliente no tiene que recordar llamar a Notify().
„ Desventaja: Ineficiencia cuando hay muchas operaciones de cambio
de estado consecutivas.
{ El Observer:
„ Ventaja: Eficiente. Evita cambios de estado intermedios
innecesarios. El cliente puede esperar a lanzar el Update() hasta
que se produzca una serie de cambios de estado.
„ Desventaja: Errores. Si se olvida llamar a Notify().

106. José Merseguer
Oscar Ansón
106
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 (con información mínima), 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).

107. José Merseguer
Oscar Ansón
107
Observer : Código

108. José Merseguer
Oscar Ansón
108
Observer : Relacionados
„ Se pueden encapsular semánticas
complejas entre subjets y observers
mediante
{ Mediator
„ Dicha encapsulación podría ser única
y globalmente accesible mediante
{ Singleton

109. José Merseguer
Oscar Ansón
109
Strategy
„ Propósito
{ Definir una familia de algoritmos,
encapsular cada uno y hacerlos
intercambiables.
„ Otros nombres
{ Policy (Política)

110. José Merseguer
Oscar Ansón
110
Strategy : Motivación
„ Existen muchos algoritmos para
parsear “strings” y romperlos
automáticamente en líneas
(linebreaking).
„ Solución
{ Implementar todos esos algoritmos
dentro de las mismas clases donde se
van a utilizar

111. José Merseguer
Oscar Ansón
111
Strategy : Motivación
„ Problema
{ Incluir el código de linebreaking en los
mismos clientes los hace más complejos
(a los clientes).
{ No siempre usaremos todos los
algoritmos en todas las situaciones.
{ Será difícil añadir nuevos algoritmos y
variar los existentes si están integrados
en los clientes.

112. José Merseguer
Oscar Ansón
112
Strategy : Motivación

113. José Merseguer
Oscar Ansón
113
Strategy : Aplicaciones
„ Usar cuando
{ Se quiera ofrecer la posibilidad de configurar
una clase con una gama de comportamientos
disponibles.
{ Se necesiten diferentes variantes de un
algoritmo.
{ Un algoritmo use datos que el cliente no tenga
por qué conocer.
{ Una clase defina varios comportamientos y
estos aparezcan en forma condicional en sus
operaciones.

114. José Merseguer
Oscar Ansón
114
Strategy : Estructura

115. José Merseguer
Oscar Ansón
115
Strategy : Participantes
„ Strategy (Compositor)
{ Declara el interfaz común para todos los algoritmos
soportados.
„ ConcreteStrategy
{ Implementa un algoritmo usando el interfaz de Strategy.
„ Context (Composition)
{ Se configura con un objeto ConcreteStrategy.
{ Mantiene una referencia a un objeto Strategy.
{ Puede definir un interfaz para permitir a Strategy
acceder a sus datos.

116. José Merseguer
Oscar Ansón
116
Strategy : Colaboraciones
„ Strategy y Context interaccionan para
implementar el algoritmo seleccionado.
„ Dos alternativas:
{ Context pasa todos los datos necesarios a Strategy a
la hora de llamar al algoritmo.
{ Context puede pasarse a si mismo como argumento en
las operaciones de Strategy
„ Context manda todas las peticiones de sus
clientes a su Strategy
{ Normalmente, los clientes pasan un objeto
ConcreteStrategy al Context.
„ Pueden elegir dentro de una familia de clases
ConcreteStrategy.

117. José Merseguer
Oscar Ansón
117
Strategy : Consecuencias
„ Familias de algoritmos relacionados
{ Mediante herencia a partir de clases
Strategy se puede factorizar
comportamientos comunes en dichas
familias
„ Se puede especializar la clase Context
para darle diferentes comportamientos
{ Acopla un comportamiento para cada
uno de los Context especializados

118. José Merseguer
Oscar Ansón
118
Strategy : Consecuencias
„ Elimina las sentencias condicionales
Switch(my_strategy)
{
case strategy_1:
algorithm_1();
break;
case strategy_2:
algorithm_2();
break;
...
case strategy_n:
algorithm_n();
break;
default:
algorithm_default();
}
strategy->Algorithm();

119. José Merseguer
Oscar Ansón
119
Strategy : Consecuencias
„ Strategy puede proveer diferentes
implementaciones del mismo
comportamiento.
„ Desventajas
{ Puede producirse sobrecarga de comunicación
en el paso de parametros entre Context y
Strategy.
„ Puede haber parámetros muy costosos de crear y NO
usados por estrategias muy simples.
{ Incrementan el número de objetos en una
aplicación.

120. José Merseguer
Oscar Ansón
120
Strategy : Implementación
„ Definición de los interfaces de Context y Strategy
„ Strategies como parametros de templates (C++).
Sólo aplicable si:
{ La estrategia se puede seleccionar en tiempo de
compilación
{ No puede ser modificada en tiempo de ejecución
„ Se pueden hacer las estrategias opcionales (Puede
NO haber un Strategy para un Context)
{ Si no existe un objeto estrategia asociado se ejecuta un
comportamiento por defecto.

121. José Merseguer
Oscar Ansón
121
Strategy : Código

122. José Merseguer
Oscar Ansón
122
Strategy : Relacionados
„ Los objetos Strategy normalmente se
emplean en
{ Flyweight

123. José Merseguer
Oscar Ansón
123
Más patrones por propósito
„ Creación
„ Estructuración
„ Comportamiento
„ Particionado
„ Concurrencia
„ GRASP (General Responsibility Assignment Software Patterns)
„ GUI (Graphic User Interface)
„ Organización de Código
„ Optimización de Código
„ Robustecimiento de Código
„ Testeo
„ Transacción
„ Arquitectura Distribuida
„ Computación Distribuida
„ Temporales
„ Bases de Datos

124. José Merseguer
Oscar Ansón
124
Más patrones por propósito
„ Creación
{ Abstract Factory (Kit, Toolkit)
{ Builder
{ Factory Method (Virtual Constructor)
{ Prototype
{ Singleton
{ Object Pool
{ . . .

125. José Merseguer
Oscar Ansón
125
Más patrones por propósito
„ Estructuración
{ Adapter (Wrapper)
{ Bridge (Handle/Body)
{ Composite (Recursive Composition)
{ Decorator (Wrapper)
{ Facade
{ Flyweight
{ Proxy (Surrogate)
{ Dynamic Linkage
{ Cache Management
{ . . .

126. José Merseguer
Oscar Ansón
126
Más patrones por propósito
„ Comportamiento
{ Chain of Responsability
{ Command (Action, Transaction)
{ Interpreter
{ Iterator (Cursor)
{ Little Language
{ Mediator
{ Memento (Token)
{ Null Object
{ Observer (Dependents, Publish-Subscribe)
{ Snapshot
{ State (Objects for States)
{ Strategy (Policy)
{ Template Method
{ Visitor
{ . . .

127. José Merseguer
Oscar Ansón
127
Más patrones por propósito
„ Particionado
{ Filter
{ Read-Only Interface
{ . . .

128. José Merseguer
Oscar Ansón
128
Más patrones por propósito
„ Concurrencia
{ Single Threaded Execution (Critical Section)
{ Lock Object
{ Lock File
{ Guarded Suspension
{ Balking
{ Scheduler
{ Read/Write Lock
{ Producer-Consumer
{ Two-Phase Termination
{ Double Buffering (Exchange Buffering)
{ Asynchronous Processing
{ Future (Promise)
{ Session Object
{ Static Locking Order
{ Optimistic Concurrency
{ Thread Pool
{ Ephemeral Cache Item
{ Transaction State Stack
{ . . .

129. José Merseguer
Oscar Ansón
129
Más patrones por propósito
„ GRASP (General Responsibility Assignment
Software Patterns)
{ Low Coupling/High Cohesion
{ Expert
{ Creator
{ Polymorphism
{ Pure Fabrication
{ Law of Demeter
{ Controller
{ . . .

130. José Merseguer
Oscar Ansón
130
Más patrones por propósito
„ GUI (Graphic User Interface)
{ Window per Task
{ Interaction Style
{ Explorable Interface
{ Conversational Text
{ Selection
{ Form
{ Direct Manipulation
{ Limited Selection Size
{ Ephemeral Feedback
{ Disabled Irrelevant Things
{ Supplementary Window
{ Step-by-Step Instructions
{ . . .

131. José Merseguer
Oscar Ansón
131
Más patrones por propósito
„ Organización de Código
{ Accesor Method Name
{ Anonymous Adapter
{ Symbolic Constant Name
{ Define Constants in Interfaces
{ Switch
{ Extend Super
{ Intention Revealing Method
{ Composed Method
{ Conditional Compilation
{ Checked Vs. Unchecked Exceptions
{ Convert Exceptions
{ Server Socket
{ Client Socket
{ . . .

132. José Merseguer
Oscar Ansón
132
Más patrones por propósito
„ Optimización de Código
{ Hashed Adapter Objects
{ Lazy Initialization
{ Double-Checked Locking
{ Loop Unrolling
{ Lookup Table
{ . . .

133. José Merseguer
Oscar Ansón
133
Más patrones por propósito
„ Robustecimiento de Código
{ Assertion Testing
{ Guaranteed Cleanup
{ Maximize Privacy
{ Return New Objects from Accesor
Method
{ Copy Mutable PArameters
{ . . .

134. José Merseguer
Oscar Ansón
134
Más patrones por propósito
„ Testeo
{ Black Box Testing
{ White Box Testing
{ Unit Testing
{ Integration Testing
{ System Testing
{ Regression Testing
{ Acceptance Testing
{ Clean Room Testing
{ . . .

135. José Merseguer
Oscar Ansón
135
Más patrones por propósito
„ Transacción
{ Acid Transaction
{ Composite Transaction
{ Two-Phase Commit
{ Audit Trail
{ . . .

136. José Merseguer
Oscar Ansón
136
Más patrones por propósito
„ Arquitectura Distribuida
{ Shared Object
{ Object Request Broker
{ Object Replication
{ Redundant Independent Objects
{ Prompt Repair
{ Mobile Agent
{ Demilitarized Zone
{ Process Pairs
{ . . .

137. José Merseguer
Oscar Ansón
137
Más patrones por propósito
„ Computación Distribuida
{ Object Identifier
{ Registry
{ Retransmission
{ Mailbox
{ Heavyweight/Lightweight
{ Heartbeat
{ Connection Multiplexing
{ . . .

138. José Merseguer
Oscar Ansón
138
Más patrones por propósito
„ Temporales
{ Time Server
{ Versioned Object
{ Temporal Property
{ . . .

139. José Merseguer
Oscar Ansón
139
Más patrones por propósito
„ Bases de Datos
{ Persistent Layer
{ CRUD
{ Stale Object
{ Type Conversion
{ IsDirty
{ Lazy Retrieval
{ . . .