Patrones de Diseño. (Design Patterns)

Transcripción

1 Patrones de Diseño (Design Patterns) 1

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 2

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? 3

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. 4

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. 5

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. 6

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 7

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 8

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). 9

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) 10

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 11

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) 12

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 13

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 14

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. 15

16 Bibliografía Design Patterns: Elements of Reusable Object-Oriented Software Gamma E., Helm R., Johnson R., Vlissides J. Addison-Wesley, 1995 ISBN:

17 Patrones de Creación Abstraen el proceso de instanciación Hacen al sistema independiente de las creaciones de objetos 17

18 Abstract Factory Propósito Proporcionar un interfaz para crear familias de objetos relacionados o dependientes sin especificar sus clases concretas. Otros nombres Kit 18

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. 19

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. 20

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 21

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(); }; 22

23 Abstract Factory : Motivación 23

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 24

25 Abstract Factory : Estructura 25

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. 26

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 27

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) 28

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 29

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);... } 30

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);}... }; 31

32 Abstract Factory : Código Crear un laberinto que puede tener bombas MazeGame game; BombedMazeFactory factory; game.createmaze(factory); 32

33 Abstract Factory : Relacionados Se pueden implementar con Factory Method Prototype Las factorias concretas suelen ser Singleton 33

34 Singleton Propósito Asegura una única instancia de una clase y provee un punto de acceso global a ella. 34

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 35

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 36

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 37

38 Singleton : Estructura 38

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 39

40 Singleton : Colaboraciones Los clientes acceden a la instancia singleton únicamente a través del método Instance() 40

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 41

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 42

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; } 43

44 Singleton : Relacionados Muchos patrones pueden implementarse usando el patrón Singleton Abstract Factory Builder Prototype 44

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 45

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. 46

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 47

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. 48

49 Composite : Motivación 49

50 Composite : Motivación 50

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 51

52 Composite : Estructura 52

53 Composite : Estructura 53

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. 54

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. 55

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) 56

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 57

58 Composite : Código 58

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 59

60 Proxy Propósito Proporciona un sustituto de otro objeto con el fin de controlar su acceso. Otros nombres Surrogate (Sucedáneo/Sustituto) 60

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. 61

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. 62

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. 63

64 Proxy : Motivación 64

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 65

66 Proxy : Estructura 66

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 67

68 Proxy : Colaboraciones El Proxy reenvía peticiones al objeto real (RealSubject) cuando lo considera conveniente. 68

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 69

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

71 Proxy : Código 71

72 Proxy : Relacionados Si ofrece un interfaz distinto (proxy de seguridad) Adapter Tiene una implementación similar a Decorator 72

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 73

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. 74

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. 75

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) 76

77 Mediator : Motivación 77

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. 78

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. 79

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. 80

81 Mediator : Motivación 81

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. 82

83 Mediator : Estructura 83

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. 84

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. 85

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. 86

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. 87

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. 88

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. 89

90 Mediator : Código 90

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 91

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 92

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 93

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. 94

95 Observer : Motivación 95

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. 96

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. 97

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). 98

99 Observer : Estructura 99

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(). 100

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. 101

102 Observer : Colaboraciones 102

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. 103

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. 104

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(). 105

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). 106

107 Observer : Código 107

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 108

109 Strategy Propósito Definir una familia de algoritmos, encapsular cada uno y hacerlos intercambiables. Otros nombres Policy (Política) 109

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 110

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. 111

112 Strategy : Motivación 112

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. 113

114 Strategy : Estructura 114

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. 115

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. 116

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 117

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(); 118

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. 119

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. 120

121 Strategy : Código 121

122 Strategy : Relacionados Los objetos Strategy normalmente se emplean en Flyweight 122

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 123

124 Más patrones por propósito Creación Abstract Factory (Kit, Toolkit) Builder Factory Method (Virtual Constructor) Prototype Singleton Object Pool

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 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 Más patrones por propósito Particionado Filter Read-Only Interface

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 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 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 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 Más patrones por propósito Optimización de Código Hashed Adapter Objects Lazy Initialization Double-Checked Locking Loop Unrolling Lookup Table

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 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 Más patrones por propósito Transacción Acid Transaction Composite Transaction Two-Phase Commit Audit Trail

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 Más patrones por propósito Computación Distribuida Object Identifier Registry Retransmission Mailbox Heavyweight/Lightweight Heartbeat Connection Multiplexing

138 Más patrones por propósito Temporales Time Server Versioned Object Temporal Property

139 Más patrones por propósito Bases de Datos Persistent Layer CRUD Stale Object Type Conversion IsDirty Lazy Retrieval