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.
Los patrones de diseño dentro del área de la ingeniería de software son diseñados con el objetivo de solventar un problema en específico, pero de forma general como para poder adecuarse a futuros requisitos y problemas.
Porfolio de diseños de Comedores de Carlotta Designpaulacoux1
calidad en el porfolio capturan la atención al detalle, la calidad de los materiales y la armonía de colores y texturas en cada diseño. El cuidadoso equilibrio entre muebles, iluminación y elementos decorativos se destaca en cada espacio, creando ambientes acogedores y sofisticados.
En resumen, la sección de porfolio de comedores de Carlotta Design es un reflejo del compromiso del equipo con la excelencia en el diseño de interiores, mostrando su habilidad para crear ambientes únicos y personalizados que sobresalen por su belleza y funcionalidad
Los patrones de diseño dentro del área de la ingeniería de software son diseñados con el objetivo de solventar un problema en específico, pero de forma general como para poder adecuarse a futuros requisitos y problemas.
Porfolio de diseños de Comedores de Carlotta Designpaulacoux1
calidad en el porfolio capturan la atención al detalle, la calidad de los materiales y la armonía de colores y texturas en cada diseño. El cuidadoso equilibrio entre muebles, iluminación y elementos decorativos se destaca en cada espacio, creando ambientes acogedores y sofisticados.
En resumen, la sección de porfolio de comedores de Carlotta Design es un reflejo del compromiso del equipo con la excelencia en el diseño de interiores, mostrando su habilidad para crear ambientes únicos y personalizados que sobresalen por su belleza y funcionalidad
Catalogo General Durstone Distribuidor Oficial Amado Salvador ValenciaAMADO SALVADOR
Descubre el catálogo general de Durstone, presentado por Amado Salvador, el distribuidor oficial de cerámica Durstone. Este catálogo incluye una amplia variedad de productos de alta calidad de Durstone, conocidos por su resistencia, durabilidad y diseño innovador. Como distribuidor oficial de cerámica Durstone, Amado Salvador ofrece una selección completa de cerámica Durstone que abarca desde baldosas para interiores y exteriores hasta soluciones personalizadas para proyectos arquitectónicos.
Durstone se destaca por su compromiso con la excelencia y la innovación en el diseño de cerámica. Cada pieza es creada para satisfacer los estándares más altos de calidad, asegurando que cada proyecto se beneficie de productos que no solo son estéticos, sino también extremadamente duraderos.
Explora este catálogo y descubre la cerámica Durstone y encuentra la opción perfecta para cualquier espacio, asegurando la mejor calidad y estilo. Amado Salvador, distribuidor oficial Durstone en Valencia.
Arquitectura Ecléctica e Historicista en Latinoaméricaimariagsg
La arquitectura ecléctica e historicista en Latinoamérica tuvo un impacto significativo y dejó un legado duradero en la región. Surgida entre finales del siglo XIX y principios del XX, esta corriente arquitectónica se caracteriza por la combinación de diversos estilos históricos europeos, adaptados a los contextos locales.
Mueble Universal la estantería que se adapta a tu entornoArtevita muebles
mueble universal con ensamblado por pieza individual para adaptarse a múltiples combinaciones y listo para integrarse fácilmente a cualquier nuevo entorno de vida, el nombre UNIVERSAL habla por sí mismo.
Gracias a su Sistema de fácil ensamblado y a su diversidad, se ha adaptado cuidadosamente a las necesidades contemporáneas de la vida moderna y puede estar seguro de que este sistema de estanterías seguirá disponible después de muchos años.
Porfolio livings creados por Carlotta Designpaulacoux1
La sección de porfolio de livings de Carlotta Design es una muestra de la excelencia y la creatividad en el diseño de interiores. Cada proyecto en el porfolio refleja la visión única y el estilo distintivo de Carlotta Design, mostrando la habilidad del equipo para transformar espacios en ambientes acogedores, elegantes y funcionales. Desde salas de estar modernas y contemporáneas hasta espacios más tradicionales y clásicos, la variedad de estilos y diseños en el porfolio demuestra la versatilidad y la capacidad del equipo para adaptarse a las necesidades y gustos de cada cliente.
Las fotografías de alta calidad en el porfolio capturan la atención al detalle, los materiales de alta calidad y la combinación de texturas y colores que hacen que cada sala de estar sea única y especial. Además, la sección de porfolio de livings de Carlotta Design destaca la integración de muebles y accesorios cuidadosamente seleccionados para crear ambientes armoniosos y sofisticados.
En resumen, la sección de porfolio de livings de Carlotta Design es una ventana a la excelencia en el diseño de interiores, mostrando el talento y la dedicación del equipo para crear espacios extraordinarios que reflejan la personalidad y el estilo de cada cliente.
El crecimiento urbano de las ciudades latinoamericanas ha sido muy rápido en las últimas décadas, debido a factores como el crecimiento demográfico, la migración del campo a la ciudad, y el desarrollo económico. Este crecimiento ha llevado a la expansión de las ciudades hacia las áreas periféricas, creando problemas como la falta de infraestructura adecuada, la congestión del tráfico, la contaminación ambiental, y la segregación social.
En muchas ciudades latinoamericanas, el crecimiento urbano ha sido desorganizado y ha resultado en la formación de asentamientos informales o barrios marginales, donde las condiciones de vida son precarias y la población carece de servicios básicos como agua potable, electricidad y transporte público.
Además, el crecimiento urbano descontrolado ha llevado a la destrucción de áreas verdes, la deforestación y la pérdida de biodiversidad, lo que tiene un impacto negativo en el medio ambiente y en la calidad de vida de los habitantes de las ciudades.
Para hacer frente a estos desafíos, las ciudades latinoamericanas están implementando políticas de planificación urbana sostenible, promoviendo la densificación urbana, la revitalización de áreas degradadas, la preservación de espacios verdes y la mejora de la infraestructura y los servicios públicos. También se están llevando a cabo programas de vivienda social y de regularización de asentamientos informales, con el objetivo de mejorar la calidad de vida de los habitantes de estas áreas.
DIA DE LA BANDERA PERUANA EL 7 DE JUNIO DE 182062946377
Diseño del dia de la bandera. El 7 de junio se celebra en todo el Perú el Día de la Bandera, una fecha que conmemora el aniversario de la Batalla de Arica de 1880, un enfrentamiento histórico en el que las tropas peruanas se enfrentaron valientemente a las fuerzas chilenas durante la Guerra del Pacífico.
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
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();
};
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
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
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
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
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
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.
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
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
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.
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
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
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)
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.
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.
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.
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.
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).
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.
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).
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.
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.
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.
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
{ . . .
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
{ . . .