Patrones de Diseño Ejemplo

Patrones de Diseño
Tema 7
Grupo 46
TACC II
Curso 2008/09
1

Indice
� IIntroducción. t d ió
� Patrones.
� Descripción de los Patrones.
� Ejemplo: Patrones en el MVC de Smalltalk.
� El catálogo de patrones.
� Patrones de Creación.
� Patrones Estructurales.
� Patrones de Comportamiento.
�� CConclusiones. l i
� Bibliografía.
2

Introducción
�� Di Diseño ñ específico ífi para el l problema, bl pero general l como
para poder adecuarse a futuros requisitos y problemas.
� Evitar el rediseño en la medida de lo posible.
� Evitar resolver cada problema partiendo de cero.
� Reutilizar soluciones que han sido útiles en el pasado.
� Patrones recurrentes de clases y comunicación entre
objetos en muchas soluciones de diseño.
3

Patrón
�� Un esquema que se usa para solucionar un problema problema.
�� El esquema ha sido probado extensivamente, y ha
funcionado. Se tiene experiencia sobre su uso.
�� EExisten i t en muchos h ddominios: i i
� Novelas y el cine: “héroe trágico”, “comedia romántica”, etc.
� Arte.
� Ingenierías.
� Arquitectura.
� Christopher p Alexander. “A Pattern Language: g g Towns, , Buildings, g ,
Construction”. 1977.
� http://www.patternlanguage.com
4

Patrones de Diseño
�� RReutilizar tili di diseños ñ abstractos b t t que no iincluyan l ddetalles t ll
de la implementación.
� Un patrón es una descripción del problema y la esencia
de su solución, que q se ppuede
reutilizar en casos
distintos.
� EEs una solución l ió adecuada d d a un problema bl común. ú
�� AAsociado i d a orientación i t ió a objetos, bj t pero el l principio i i i
general es aplicable a todos los enfoques de diseño
software.
5

Patrones de Diseño
�� DDocumentar t lla experiencia i i en el l di diseño, ñ en
forma de un catálogo de patrones.
� Categorías de patrones:
� De creación: implica el proceso de instanciar objetos.
� Estructurales: composición de objetos.
�� De comportamiento comportamiento: cómo se com comunican nican los objetos objetos,
cooperan y distribuyen las responsabilidades para
lograr sus objetivos.
6

Patrones de Diseño
Estructura de un patrón
�� NNombre b del d l patrón. t ó
� Describe el problema de diseño, junto con sus soluciones y
consecuencias.
�� VVocabulario b l i dde di diseño. ñ
� Problema.
� Describe cuándo aplicar el patrón.
� Explica el problema y su contexto.
� Solución.
�� Elementos que forman el diseño, relaciones, responsabilidades.
� No un diseño concreto, sino una plantilla que puede aplicarse en
muchas situaciones distintas.
�� Consecuencias
Consecuencias.
� Resultados, ventajas e inconvenientes de aplicar el patrón.
� P.ej.: relación entre eficiencia en espacio y tiempo; cuestiones de
implementación implementación, etc etc.
7

Patrones de Diseño
Ejemplo: MVC de Smalltalk
�Modelo/Vista/Controlador.
C
D
B
A
A B C D
X 60 20 15 5
Y 40 25 15 20
Z 10 10 20 60
Modelo
A: 40%
B: 25%
CC: 15%
D: 20%
40
30
20
10
0
A B C D
8

Patrones de Diseño
Ejemplo: MVC de Smalltalk
�� SSeparar llos objetos bj t con llos ddatos t ( (modelo), d l ) sus
visualizaciones (vistas) y el modo en que la interfaz
reacciona ante la entrada al usuario (controlador).
( )
� Separar p estos componentes, p ppara
aumentar la
flexibilidad y reutilización.
� DDesacoplar l vistas i dde modelos, d l mediante di un protocolo l dde
subscripción/notificación.
� Cada vez que cambian los datos del modelo, avisar a
las vistas que q dependen p
de él. Estas se actualizan.
9

Patrones de Diseño
Ejemplo: MVC de Smalltalk
�� Patrón Observer Observer, más general (dependencias entre
objetos).
� Las vistas se pueden anidar: Vistas compuestas y
simples.
�� Generalización: Patrón Composite Composite.
� La relación entre la vista y el controlador: patrón
St Strategy t ( (un objeto bj t que representa t un algoritmo). l it )
�� Otros patrones:
� Factory Method: especifica la clase controlador predeterminada
para una vista.
�� Decorator: Añade capacidad de desplazamiento a una vista vista.
10

El catálogo de patrones
Ámmbito
Propósito
Creación Estructurales De Comportamiento
Clase Factory Method Adapter (de clases) Interpreter.
Template Method. Method
Objeto j Abstract Factory Adapter (de objetos). Chain of Responsibility.
Builder
Bridge.
Command.
Prototype Composite.
Iterator.
Singleton Decorator.
Mediator.
Facade.
Memento.
Flyweight.
Observer.
Proxy. State.
Strategy.
Visitor.
11

El catálogo
de patrones
Relaciones entre
los patrones.
12

Indice
�� Introducción
Introducción.
� Patrones de Creación.
�Singleton
�Singleton.
�Abstract Factory.
�Factory Method.
� Patrones Estructurales.
� Patrones de Comportamiento.
�� Concl Conclusiones. siones
� Bibliografía.
13

Patrones de Creación
�� Ab Abstraen t el l proceso de d instanciación
i t i ió
� Ayudan a que el sistema sea independiente de
cómo se crean crean, componen y representan los
objetos.
� Flexibilizan:
� qué se crea
� quién lo crea
� cómo se crea
� cuándo se crea
�� Permiten configurar un sistema:
� estáticamente (compile-time)
� dinámicamente (run-time) ( )
14

Singleton
�� IIntención. t ió
� Asegurar que una clase tiene una única instancia y proporciona un
punto de acceso global a dicha instancia.
� Motivación.
� Hay veces que es importante asegurar que una clase tenga una
sola instancia instancia, por ejemplo:
� Un gestor de ventanas
� Una única cola de impresión
� Un único sistema de ficheros
� Un único fichero de log, o un único repositorio.
� ¿Cómo asegurarlo? una variable global hace el objeto
accesible accesible, pero se puede instanciar varias veces veces.
� Responsabilidad de la clase misma: actuar sobre el
mensaje de creación de instancias
15

Singleton
� Aplicabilidad.
� Cuando debe haber una sola instancia, y debe ser accesible a los
clientes desde un punto de acceso conocido.
� Cuando la única instancia debe ser extensible mediante
subclasificación, y los clientes deben ser capaces de usar una
instancia extendida sin modificar su código código.
� Estructura.
Singleton
static Singleton uniqueInstance
singletonData
static Singleton Instance ()
SingletonOperation ()
GetSingletonData ()
return uniqueInstance
16

Singleton
� Participantes: p
� Singleton:
� Define una operación de clase, llamada “Instance” que deja a los clientes
acceder a la única instancia.
� Puede ser responsable de crear su única instancia.
� Colaboraciones:
� Los clientes acceden a la instancia de un Singleton a través de la
operación “Instance”.
� Consecuencias:
� Acceso controlado a la única instancia.
� Espacio de nombre reducido. Mejora sobre el uso de variables
globales.
� Permite el refinamiento de operaciones p y la representación. p Se puede p
subclasificar de la clase Singleton y configurar la aplicación con una
instancia de esta clase.
� Fácil modificación para permitir un número variable de instancias.
� Más flexible que las operaciones de clase.
17

Singleton
�Implementación:
�Implementación:
class Singleton {
private: p
static Singleton* _instance;
void otherOperations();
protected:
Singleton();
public:
static Singleton* getInstance();
};
Singleton* Singleton::_instance = 0;
Singleton* Singleton::getInstance() {
if (_instance == 0 )
_instance instance = new Singleton;
return _instance;
}
18

#include "stdafx.h"
#include
using namespace std;
class Maze{
int x, y;
public:
};
M Maze(int (i x, i int y) ) : x(x), ( ) y(y) ( ) {}
class MazeFactory {
public: bli
static MazeFactory* Instance();
// existing interface goes here
Maze * createMaze(int x, int y) { return new Maze(x, y); };
protected: t t d
MazeFactory() {};
private:
static MazeFactory* _instance;
};
MazeFactory* MazeFactory::_instance = 0;
MMazeFactory* F t * MazeFactory::Instance M F t I t () {
if (_instance == 0) _instance = new MazeFactory;
return _instance;
}
void main(){
Maze * m = MazeFactory::Instance()->createMaze(10,10);
}
Ejemplo
19

Singleton
� Implementación:
� Creación de una subclase de singleton.
�� DDeterminar t i qué é singleton i l t queremos usar en lla operación ió “I “Instance”. t ”
� Registro de objetos singleton.
class Singleton {
public:
static void Register(const char* name, Singleton*);
static Singleton* Singleton Instance();
protected:
static Singleton* Lookup(const char* name);
private:
static Singleton* _instance;
static List* _registry;
};
Si Singleton* l t * Si Singleton::Instance l t I t () {
if (_instance == 0) {
const char* singletonName =getenv("SINGLETON");
// user use oor eenvironment o e supp supplies es this s aat sstartup a up
_instance = Lookup(singletonName); // Lookup returns 0 if there's no such singleton
}
return _instance; }
20

Singleton
� ¿Dónde se registra la clase?
� Una posibilidad es en el constructor.
MySingleton::MySingleton() {
// ...
Singleton::Register("MySingleton", g g ( y g this); )
}
�Entonces hay que instanciar la clase!
�Se puede crear una instancia global:
static MySingleton theSingleton;
21

Singleton g
Ejemplo
class MazeFactory {
public:
static MazeFactory* Instance();
// existing g interface ggoes
here
protected:
MazeFactory();
private:
static MazeFactory MazeFactory* _instance; instance;
};
MazeFactory* MazeFactory::_instance = 0;
MazeFactory* MazeFactory MazeFactory::Instance () {
if (_instance == 0) {
const char* mazeStyle = getenv("MAZESTYLE");
if (strcmp(mazeStyle, "bombed") == 0)
_instance i t = new BBombedMazeFactory; b dM F t
} else if (strcmp(mazeStyle, "enchanted") == 0)
_instance = new EnchantedMazeFactory;
// ... other possible subclasses
} else
_instance = new MazeFactory;
return _instance;
}
22

Abstract Factory
�� PPropósito. ó it
� Proporciona una interfaz para crear familias de objetos
relacionados o que dependen entre sí, sin especificar sus
clases l concretas.
� También Conocido Como.
�� Kit Kit.
� Motivación.
� Ej.: un framework para la construcción de interfaces de usuario
que permita varios “ “look and f feel” ” ( (ej.: Motiff y Presentation
Manager).
� Una clase abstracta WidgetFactory con la interfaz para crear
cada tipo de widget widget.
� Una clase abstracta para cada tipo de widget. Subclases
concretas que implementan cada widget concreto.
�� De esta manera manera, los clientes son independientes del look
and feel concreto.
23

Abstract Factory
� Motivación.
WidgetFactory
CreateScrollBar()
CreateWindow()
MotifWidgetFactory PMWindowFactory
CreateScrollBar()
CreateWindow()
Familias
CreateScrollBar()
CreateWindow()
PMWindow
PMScrollBar
Productos
Window
MotifWindow
ScrollBar
MotifScrollBar
Client
24

Abstract Factory
� Aplicabilidad. Usar este patrón cuando:
�un sistema que deba ser independiente de cómo se
crean, componen y representan sus productos. d
�un sistema que deba ser configurado con una familia de
productos entre varias varias.
�una familia de objetos producto relacionados que está
diseñada para ser usada conjuntamente conjuntamente, y es necesario
hacer cumplir esta restricción.
�se quiere q proporcionar p p una biblioteca de clases
productos, y sólo se quiere revelar sus interfaces, no su
implementación.
25

Abstract Factory
�Estructura:
ConcreteFactory1
AbstractFactory
Productos
createProductA ()
createProductB () AbstractProductA
Familias
ConcreteFactory2
createProductA () createProductA ()
createProductB () createProductB ()
ProductA2
ProductA1
AbstractProductB
ProductB2
ProductB1
Client
26

Abstract Factory
� Participantes: p
� AbstractFactory. Declara una interfaz para operaciones que
crean objetos producto abstractos.
� ConcreteFactory. y Implementa p las operaciones p para p crear objetos j
producto concretos.
� AbstractProduct. Declara una interfaz para un tipo de objeto
producto.
� ConcreteProduct. Define un objeto producto para que sea creado
por la fábrica correspondiente.
� Client. Sólo usa interfaces declaradas por las clases
Ab AbstractFactory t tF t y Ab AbstractProduct.
t tP d t
� Colaboraciones.
� Normalmente sólo se crea una única instancia de una clase
ConcreteFactory en tiempo de ejecución. Esta fábrica concreta
crea objetos producto que tienen una determinada
implementación.
�� Ab AbstractFactory t tF t ddelega l lla creación ió dde objetos bj t producto d t en su
subclase ConcreteFactory.
27

Abstract Factory
�Consecuencias.
C i
�Aísla las clases concretas. Ayuda a controlar
las clases de objetos que crea una aplicación.
Aísla a los clientes de las clases de
implementación
implementación.
�Facilita el reemplazo de familias de productos.
�P �Promueve lla consistencia i t i entre t productos d t ( (que
la aplicación use objetos de una sola familia a
la vez) vez).
�Es difícil añadir un nuevo producto.
28

Abstract Factory
Ejemplo
� Ejemplo: aplicación para construir uncocheapartir
de unas partes (motor, chasis, ...)
� ttodos d llos componentes t dde lla misma i marca (f (familia) ili )
� hay múltiples marcas (Ford, Toyota, Opel, ...)
� es responsabilidad p del cliente ensamblar las piezas p
CarEngine
CarPart
FordEngine ToyotaEngine PorscheEngine
Car
FordCar ToyotaCar PorscheCar
CarBody
FordBody ToyotaBody PorscheBody
29

Abstract Factory
Ejemplo (ii)
� � ¿Cómo lo haríamos sin utilizar el patrón Abstract Factory?
En un método del cliente:
CrearCoche (string marca) {
}
if (marca == “ford”)
FordCar coche = new FordCar ()
else if (marca == “toyota”)
ToyotaCar coche = new ToyotaCar ()
else …;
if (marca == “ford”)
FordEngine motor = new FordEngine ()
else if (marca == “toyota”)
ToyotaEngine motor = new ToyotaEngine ()
else …;
coche.add (motor);
...
return coche;
El código del cliente
decide qué clase de
coche construir (bien)
y qué subpartes
instanciar (mal). Puede
cometerse el error de
ensamblar partes de
distintas familias familias.
30

Abstract Factory
Ejemplo (iii)
ToyotaFactory
makeCar ()
makeBody ()
makeEngine ()
CarPartFactory
makeCar ()
makeBody y() ()
makeEngine ()
Familias
FordFactory
FordBody
Productos
CarBody
CarEngine
ToyotaBody
makeCar ()
makeBody ()
makeEngine () FordEngine ToyotaEngine
FordCar
Car
ToyotaCar
Client
31

Abstract Factory
Ejemplo (iv)
� Utilizando el patrón, éste fuerza a que todos los productos sean de la
misma familia, una vez establecida ésta por el cliente.
� El patrón permite separar la elección de la familia (la marca del
coche) del proceso de instanciar las partes.
� En el cliente:
Car hacerCoche () {
Car coche=familia.makeCar();
coche.addEngine (familia.makeEngine());
coche.addBody (familia.makeBody ());
...
return t coche; h
}
32

Abstract Factory
Ejemplo (v)
�� familia contiene una instancia de una marca de coche coche.
� ¿Cómo se instancia familia?
//presenta por pantalla la selección
class CrearCocheGUI : public CFrameWnd {
//….
void id OOnButtonClicked B tt Cli k d () {
string familiasel;
CrearCoche assembler;
Car coche;
// //…
if (familiasel == “ford”)
assembler=CrearCoche::using (new FordFactory())
else if (familiasel == “toyota”)
assembler=CrearCoche::using bl C C h i ( (new TToyotaFactory()) t F t ())
else …;
coche = assembler.hacerCoche();
}
}
class CrearCoche {
CarPartFactory y * familia; ;
Car hacerCoche () {
Car coche=familia->makeCar();
coche.addEngine g ( (familia->makeEngine()); g ());
coche.addBody (familia->makeBody ());
...
return coche;
}
static CrearCoche using (CarPartFactory * f) {
CrearCoche l;
l.factory y(); (f);
return l;
}
void factory y( (CarPartFactory y * f) ){ {
familia=f;
}
}
33

Abstract Factory
Otro Ejemplo: Laberinto
MazeFactory
+MakeMaze(): Maze
+MakeWall(): Wall
+MakeRoom(int n): Room
+MakeDoor(Room r1, Room r2): Door
EnchantedMazeFactory
+MakeRoom(int n): EnchantedRoom
+MakeDoor(Room r1, Room r2):
DoorNeedingSpell
BombedMazeFactory
+MakeRoom(int n): RoomWithABomb
+MakeWall(): BombedWall
MazeGame
+CreateMaze(MazeFactory): Maze
Maze Wall Room
Door
DoorNeeding
Spell
Bombed
Wall
Enchanted
Room
RoomWithA
Bomb
34

Abstract Factory
Otro Ejemplo: Laberinto
class MazeFactory {
public:
MazeFactory();
virtual it lM Maze* *MMakeMaze() k M () const t
{ return new Maze; }
virtual Wall* MakeWall() const
{ return new Wall; ; }
virtual Room* MakeRoom(int n) const
{ return new Room(n); }
virtual Door* MakeDoor(Room* r1, Room* r2) const
{ return t new Door(r1, D ( 1 r2); 2) }
};
35

Abstract Factory
Otro Ejemplo
Maze* MazeGame::CreateMaze (MazeFactory& factory) {
Maze* aMaze = factory.MakeMaze();
Room* Room r1 = factory.MakeRoom(1);
Room* r2 = factory.MakeRoom(2);
Door* aDoor = factory.MakeDoor(r1, r2);
aMaze->AddRoom(r1);
aMaze->AddRoom(r2);
M AddR ( 2)
r1->SetSide(North, factory.MakeWall());
r1->SetSide(East, aDoor);
r1->SetSide(South, ( , factory.MakeWall());
y ());
r1->SetSide(West, factory.MakeWall());
r2->SetSide(North, factory.MakeWall());
r2->SetSide(East, factory.MakeWall());
r2->SetSide(South, 2 >S tSid (S th factory.MakeWall());
f t M k W ll())
r2->SetSide(West, aDoor);
return aMaze;
}
36

Abstract Factory
Otro Ejemplo
class EnchantedMazeFactory : public MazeFactory {
public:
EnchantedMazeFactory();
virtual Room* MakeRoom(int n) const
{ return new EnchantedRoom(n, CastSpell()); }
virtual Door* MakeDoor(Room* r1, Room* r2) const
{ return new DoorNeedingSpell(r1, g p ( , r2); );
}
protected:
Spell* CastSpell() const;
};
// Make it possible to have rooms with bombs
Wall* Wall BombedMazeFactory::MakeWall () const {
return new BombedWall;
}
Room* BombedMazeFactory::MakeRoom(int n) const {
return t new RoomWithABomb(n);
R WithAB b( )
}
MazeGame game;
BombedMazeFactory y factory; y;
game.CreateMaze(factory);
37

Factory Method
�� PPropósito. ó it
� Define una interfaz para crear un objeto, pero deja que
sean las subclases quienes q decidan qué q clase instanciar.
Permite que una clase delegue en sus subclases la
creación de objetos.
�� También Conocido Como.
� Virtual Constructor.
� Motivación.
� Ej.: un framework que pueda presentar distintos tipos de
documentos (similar a MFCs).
�Dos abstracciones clave: aplicación p y documento (ambas (
clases abstractas). Hay que subclasificarlas.
�La clase aplicación no sabe qué subclase documento
instanciar.
38

Factory Method
� Motivación.
Documento
+Abrir() b ()
+Cerrar()
+Guardar()
+Deshacer()
MiDocumento
docs
1..*
Aplicacion
+CrearDocumento()
CrearDocumento()
+NuevoDocumento()
+AbrirDocumento()
MiAplicacion
+CrearDocumento()
C D t ()
Se le llama “factory method” (método
de fabricación)
Documento * doc = CrearDocumento()
ddocs.push_back(doc) h b k(d )
doc->Abrir()
return new MiDocumento
39

Factory Method
� AAplicabilidad. li bilid d UUsar este patrón ó cuando: d
� Una clase no puede prever la clase de los objetos que tiene que crear.
�� Una clase quiere que sean sus subclases las que decidan qué objetos
crean.
� Las clases delegan la responsabilidad en una de entre varias clases
auxiliares auxiliares, y queremos localizar qué subclase concreta es en la que se
delega.
� Estructura.
PProduct d t
Creator
+FactoryMethod()
+AnOperation()
CConcreteProduct t P d t CConcreteCreator t C t
+FactoryMethod()
//…
product = factoryMethod()
//…
return new ConcreteProduct
40

Factory Method
�� PParticipantes. ti i t
� Product (Documento). Define la interfaz de los objetos que crea
el factoryy method.
� ConcreteProduct (MiDocumento). Implementa la interfaz del
producto.
�� Creator (Aplicacion) (Aplicacion). Declara el factory method method. Puede también
dar una implementación por defecto del factory method, que
devuelve un objeto de una clase por defecto.
�� ConcreteCreator (MiAplicacion) (MiAplicacion). Sobreescribe el factory
method para devolver una instancia de ConcreteProduct.
� Colaboraciones.
� El creator se apoya en sus subclases para definir el método de
fabricación de manera que éste devuelva una instancia del
ConcreteProduct adecuado.
41

Factory Method
�� Consecuencias
Consecuencias.
�Los métodos de fabricación eliminan la necesidad de
ligar g clases específicas p de la aplicación p a nuestro
código.
�El �El código sólo trata con la interfaz Product Product, puede
funcionar con cualquier clase ConcreteProduct
definida por el usuario.
�Proporciona enganches para las subclases. Crear
objetos con un método de fabricación es más flexible
que hacerlos directamente.
�El �El ffactory t method th d es un hhook k method th d para que llas
subclases den una versión extendida del código.
42

Factory Method
�Consecuencias.
Figure Manipulator
…
+DownClick()
+CreateManipulator() p ()
+Drag() g()
…
+UpClick()
LineFigure
TextFigure
LineManipulator
…
…
+DownClick()
+CreateManipulator() +CreateManipulator() +Drag()
+UpClick()
TextManipulator
+DownClick()
+Drag()
+UpClick()
43

Factory Method
�Implementación.
I l t ió
�Dos variantes principales:
� Cuando la clase Creator es abstracta y no
proporciona implementación para el método de
fabricación que declara declara.
�Cuando la clase Creator es concreta y proporciona
una implementación predeterminada para el método
de fabricación.
�Métodos de fabricación parametrizados:
�Que Q llos ffactory t methods th d creen varios i ti tipos dde
producto. El método recibe un parámetro que
identifica el tipo p deobjeto j
a crear.
44

Factory Method
�Implementación.
class Creator {
public:
Product* GetProduct();
protected:
virtual Product* CreateProduct(); // factory method
private:
Product* _product;
};
Product* Creator::GetProduct () {
if (_product ( d t == 0) {
_product = CreateProduct();
}
ret return rn _product; prod ct
}
45

Factory Method
� Implementación. Se pueden usar plantillas para evitar
la herencia (múltiples subclases de Creator).
class Creator {
public:
virtual Product* CreateProduct() = 0;
// pure virtual factory method
};
template
class StandardCreator: public Creator {
public:
virtual TheProduct* CreateProduct();
};
template
TheProduct*
StandardCreator::CreateProduct () {
return new TheProduct;
}
// El cliente proporciona sólo la clase del
// producto, no necesita hacer una
// nueva clase que herede de creator.
class MyProduct : public Product {
public:
MyProduct();
// ...
};
StandardCreator myCreator;
46

Factory Method
Ejemplo
class MazeGame {
public:
Maze* CreateMaze(); ();
// factory methods:
virtual Maze* MakeMaze() const
{ return new Maze; }
virtual Room* MakeRoom(int n) const
{ return new Room(n); }
virtual Wall* MakeWall() const
{ return new Wall; }
virtual Door* MakeDoor(Room* r1, Room* r2) const
{ return new Door(r1, r2); }
};
Maze* MazeGame::CreateMaze () {
Maze* aMaze = MakeMaze();
Room* Room r1 = MakeRoom(1);
Room* r2 = MakeRoom(2);
Door* theDoor = MakeDoor(r1, r2);
aMaze->AddRoom(r1);
aMaze->AddRoom(r2);
M AddR ( 2)
r1->SetSide(North, MakeWall());
r1->SetSide(East, theDoor);
r1->SetSide(South, ( , MakeWall()); ());
r1->SetSide(West, MakeWall());
r2->SetSide(North, MakeWall());
r2->SetSide(East, MakeWall());
r2->SetSide(South, 2 >S tSid (S th MakeWall());
M k W ll())
r2->SetSide(West, theDoor);
return aMaze;
}
47

Factory Method
Ejemplo
class BombedMazeGame : public MazeGame {
public:
BombedMazeGame();
virtual Wall* Wall MakeWall() const
{ return new BombedWall; }
virtual Room* MakeRoom(int n) const
{ return new RoomWithABomb(n); }
};
class EnchantedMazeGame : public MazeGame {
public: bli
EnchantedMazeGame();
virtual Room* MakeRoom(int n) const
{ return new EnchantedRoom(n, ( , CastSpell()); p ()); }
virtual Door* MakeDoor(Room* r1, Room* r2) const
{ return new DoorNeedingSpell(r1, r2); }
protected:
SSpell* ll* CCastSpell() tS ll() const; t
};
48

Indice
�� IIntroducción. t d ió
� Patrones de Creación.
�Patrones P t EEstructurales. t t l
�Composite.
Co pos te
�Facade.
�Pro �Proxy.
�Adapter.
� Patrones de Comportamiento.
� Conclusiones.
� Bibliografía.
49

Patrones Estructurales
� Etbl Establecen cómo ó se componen clases l y objetos bj t
para formar estructuras mayores que
implementan nueva funcionalidad
funcionalidad.
� Los patrones de clase usan la herencia para
componer interfaces o implementaciones (ej (ej.: :
Adapter).
�� Los patrones de objeto objeto, describen maneras de
componer objetos para implementar nueva
funcionalidad
funcionalidad.
� Flexibilidad, ya que se puede cambiar la configuración
en tiempo de ejecución.
50

Composite
� Propósito.
� componer objetos en estructuras arborescentes para
representar jerarquías parte-conjunto.
�� MMotivación. ti ió
Linea
dibuja ()
� Aplicaciones gráficas. Manipulación de grupos de figuras de
manera uniforme uniforme.
Rectangulo
dibuja ()
Grafico
dibuja ()
Texto
dibuja ()
*
graficos
Dibujo
dibuja ()
añade (Grafico g)
elimina (Grafico g)
obtenHijo (int)
para todo g en graficos
g.dibuja ()
añadir g a la lista de
graficos:
graficos.addElement (g)
51

Composite
�� Una instancia en tiempo de ejecución:
graficos
:Dibujo
:Dibujo
graficos graficos graficos
graficos
:Rectangulo :Texto
:Linea :Texto

Composite
� Aplicabilidad. Usar el patrón cuando:
� Se quieren representar jerarquías todo/parte de objetos.
� Se quiere que los clientes ignoren la diferencia entre composiciones de
objetos j y objetos j individuales. Los clientes tratarán todos los objetos j en
la estructura compuesta de manera uniforme.
� Estructura.
Client Component
+ Operation()
+ Add(Component)
( p )
+ Remove(Component)
+ GetChild(int)
Leaf
+ Operation()
*
children
Composite
+ Operation() p ()
+ Add(Component)
+ Remove(Component)
+ GetChild(int)
forall g in children:
g.Operation()
O ti ()
53

Composite
� Participantes. p
� Component (Grafico).
� Declara la interfaz de los objetos de la composición.
� Implementa p el comportamiento p por p defecto de la interfaz común a
todas las clases.
� Declara las interfaces para acceder y gestionar los hijos.
� (opcional) Define una interfaz para acceder al padre de un componente
en la estructura recursiva y la implementa implementa, si es apropiado apropiado.
� Leaf (Linea, Rectangulo, …).
� Representa objetos hoja en la composición. Una hoja no tiene hijos.
�� Define el comportamiento de los objetos primitivos en la composición
composición.
� Composite (Dibujo)
� Define el comportamiento de los objetos con hijos en la composición.
�� Almacena componentes hijo hijo.
� Implementa operaciones relacionadas con los hijos de la interfaz de
Component.
�� Client Client.
� Manipula objetos en la composición a través de la interfaz de
54
Component.

Composite
�� Colaboraciones
Colaboraciones.
� Los clientes usan el interfaz de la clase Component para
interaccionar con los objetos de la estructura compuesta.
�� Si ell objeto bj t eshoja, h j entonces t lla petición ti ió secursadirectamente.
di t t
� Si el objeto es un Composite, entonces normalmente redirige las
peticiones a sus objetos hijo, quizá realizando operaciones
adicionales antes y/o después de la redirección.
� Consecuencias. El patron composite:
�� Define jerarquías de objetos primitivos y compuestos compuestos. Cuando
un código cliente espera un objeto simple, se puede reemplazar
por uno compuesto.
�� Simplifica el cliente cliente. Se pueden tratar objetos simples y
compuestos de manera uniforme.
� Facilita añadir nuevos tipos de componente.
� Puede hacer el diseño demasiado general. Complicado restringir
los tipos de componente de un composite.
55

Composite
�� IImplementación. l t ió Al Algunas ddecisiones: i i
� Referencias explícitas a los padres. En la clase component.
�� Compartir componentes. Útil para ahorrar memoria, pero la
gestión de un componente que tiene más de un padre es difícil.
� Maximizar la interfaz del componente.
�� Declaración de las operaciones de gestión de hijos hijos. Equilibrio
entre seguridad y transparencia:
� Declararla en la raíz da transparencia. Es menos seguro porque el
cliente puede tratar de hacer cosas sin sentido sobre objetos hoja hoja.
� Declararla en la clase compuesto da seguridad, pero perdemos
transparencia: leafs y composites tienen interfaces distintas.
�� A veces es necesario tener en cuenta un orden para los hijos hijos.
� ¿Quién debe borrar los componentes?
� ¿Cuál es la mejor estructura de datos para almacenar los
componentes?.
?
56

Composite
Ejemplo
class Equipment {
public:
virtual ~Equipment();
const char* Name() { return _name; }
virtual it lWWatt ttP Power(); ()
virtual Currency NetPrice();
virtual Currency DiscountPrice();
virtual void Add(Equipment*);
Add(Equipment );
virtual void Remove(Equipment*);
virtual Iterator* CreateIterator() {return 0;}
protected:
EEquipment(const i t( t char*); h *)
private:
};
const char* _name;
57

Composite
Ejemplo
class FloppyDisk : public Equipment {
public: p
FloppyDisk(const char*);
virtual ~FloppyDisk();
virtual Watt Power();
virtual Currency NetPrice();
virtual Currency DiscountPrice();
};
class CompositeEquipment : public Equipment {
public:
virtual ~CompositeEquipment();
virtual Watt Power(); ();
virtual Currency NetPrice();
virtual Currency DiscountPrice();
virtual void Add(Equipment*);
virtual void Remove(Equipment*);
virtual Iterator* CreateIterator();
protected:
CompositeEquipment(const p q p ( char*); )
private:
List _equipment;
};
58

Composite
Ejemplo
Currency CompositeEquipment::NetPrice () {
Iterator* i = CreateIterator();
Currency total = 0;
for (i->First(); (i >First(); !i->IsDone(); !i >IsDone(); i i->Next()) >Next()) {
}
total += i->CurrentItem()->NetPrice();
}
delete i;
return total;
class Chassis : public CompositeEquipment {
public:
Chassis(const char*);
virtual ~Chassis();
};
virtual it lWWatt ttP Power(); ()
virtual Currency NetPrice();
virtual Currency DiscountPrice();
59

Composite
Ejemplo
using namespace std;
void main()
{
Cabinet* cabinet = new Cabinet("PC Cabinet");
Chassis* chassis = new Chassis( Chassis("PC PC Chassis Chassis"); );
cabinet->Add(chassis);
Bus* bus = new Bus("MCA Bus");
}
bus->Add(new ( Card("16Mbs ( Token Ring")); g ))
chassis->Add(bus);
chassis->Add(new FloppyDisk("3.5in Floppy"));
cout

Facade
� Propósito.
� Proporciona p una interfaz unificada paraunconjunto p j de interfaces de un
subsistema.
� Define una interfaz de alto nivel que hace que el subsistema sea más fácil
de usar.
� Motivación.
� Estructurar un sistema en subsistemas ayuda a reducir su complejidad.
�� Un objetivo típico de diseño es minimizar la comunicación y dependencias
entre subsistemas.
� Un modo de conseguir esto es introducir un objeto fachada que
proporcione una interfaz única y simplificada a los servicios más generales
del subsistema.
61

Facade
� Motivación.
62

Facade
� Aplicabilidad. Usar el patrón cuando:
� Queramos proporcionar una interfaz simple a un subsistema complejo.
Sólo los clientes que necesitan más personalización necesitarán ir más
allá de la fachada.
� Haya muchas dependencias entre los clientes y las clases que
implementan una abstracción. La fachada desacopla el subsistema de
sus clientes y otros subsistemas (mejora acoplamiento y portabilidad).
� Queramos dividir en capas nuestros subsistemas. La fachada es el
punto de entrada a cada subsistema.
�� EEstructura. t t
63

Facade
�� Participantes
Participantes.
� Facade (Compiler).
� Sabe qué clases del subsistema son las responsables ante una
petición petición.
� Delega las peticiones de los clientes en los objetos apropiados del
subsistema.
�� Clases del Subsistema (Scanner (Scanner, Parser Parser, ProgramNodeBuilder
ProgramNodeBuilder,
CodeGenerator).
� Implementan la funcionalidad del subsistema.
� Realizan las labores encomendadas por p el objeto j Facade.
� No tienen referencias al objeto Facade.
� Observaciones.
�� Los clientes se comunican en el sistema enviando peticiones al
objeto Facade, que las reenvía a los objetos apropiados.
� Los clientes que usan la fachada no tienen que acceder
directamente a los objetos del subsistema.
64

Facade
�� CConsecuencias. i
� Oculta a los clientes los componentes del sistema, haciendo
el sistema más fácil de usar.
� Promueve acoplamiento débil entre el subsistema y sus
clientes.
�� Elimina dependencias y puede reducir el tiempo de
compilación.
� No impide que las aplicaciones usen las clases del
subsistema en caso necesario necesario.
� Implementación. Factores a tener en cuenta:
�� Reducción del acoplamiento cliente-subsistema. cliente subsistema. Clase
facade abstracta, con clases concretas para las diferentes
implementaciones de un subsistema.
�� Clases del subsistema públicas o privadas privadas. Uso de espacios
de nombres en C++.
65

Facade
Ejemplo: Una fachada para un sistema de compilación
class Scanner {
public:
Scanner(istream&);
virtual ~Scanner();
virtual it lTk Token& &S Scan(); ()
private:
};
istream& _inputStream;
class Parser {
public:
Parser();
virtual ~Parser();
virtual void Parse(Scanner&, ProgramNodeBuilder&);
}; }
66

Facade
Ejemplo: Una fachada para un sistema de compilación
class ProgramNodeBuilder g {
public:
ProgramNodeBuilder();
virtual ProgramNode* NewVariable ( const char* variableName ) const;
virtual ProgramNode* NewAssignment ( ProgramNode* variable variable,
ProgramNode* expression) const;
virtual ProgramNode* NewReturnStatement ( ProgramNode* value ) const;
virtual ProgramNode* g NewCondition ( ProgramNode* g condition,
ProgramNode* truePart,
ProgramNode* falsePart ) const;
// ...
ProgramNode* ProgramNode GetRootNode();
private:
ProgramNode* _node;
};
67

Facade
Ej Ejemplo: l Una U ffachada h d para un sistema i t de d compilación il ió
class ProgramNode {
public:
// program node manipulation
virtual void GetSourcePosition(int& line, int& index);
// ...
// child manipulation
virtual void Add(ProgramNode*);
virtual void Remove(ProgramNode*);
// ...
virtual void Traverse(CodeGenerator&);
protected:
ProgramNode();
};
class CodeGenerator {
public:
virtual void Visit(StatementNode*);
virtual it lvoid idVi Visit(ExpressionNode*);
it(E i N d *)
// ...
protected:
CodeGenerator(BytecodeStream&);
CodeGe e a o ( y ecodeS ea &);
protected:
BytecodeStream& _output;
};
68

Facade
Ejemplo: Una fachada para un sistema de compilación
void ExpressionNode::Traverse (CodeGenerator& cg) {
cg.Visit(this); Vi it(thi )
ListIterator i(_children);
for (i.First(); !i.IsDone(); i.Next()) {
i.CurrentItem()->Traverse(cg);
() ( g);
}
}
class Compiler { // Clase Facade
public: bli
Compiler();
virtual void Compile(istream&, BytecodeStream&);
};
void Compiler::Compile ( istream& input, BytecodeStream& output ) {
Scanner scanner(input);
PProgramNodeBuilder N d B ild bbuilder; ild
Parser parser;
parser.Parse(scanner, builder);
RISCCodeGenerator generator(output);
g ( p );
ProgramNode* parseTree = builder.GetRootNode();
parseTree->Traverse(generator);
}
69

Proxy
�� Propósito Propósito.
� Proporcionar un representante o substituto de otro objeto
para controlar el acceso a este.
� También conocido como.
� Surrogate (substituto).
�� MMotivación. ti ió
� Retrasar el coste de creación e inicialización de un objeto
hasta que q sea realmente necesario.
� Ej.: al abrir un documento, no abrir las imágenes que no sean
visibles.
aTextDocument:
image
en memoria
anImageProxy:
fileName
data
anImage:
en disco
70

Proxy
�Motivación.
71

Proxy
�� Aplicabilidad
Aplicabilidad.
� Cuando hay necesidad de una referencia a un objeto más
flexible o sofisticada que un puntero.
� Proxy Remoto: un representante para un objeto que se
encuentra en otro espacio de direcciones.
� Proxy Virtual: Crea objetos costosos por encargo (ej.:
IImageProxy). P )
� Proxy de Protección: Controla el acceso al objeto original
(permisos de acceso).
� Referencia inteligente: sustituto de un puntero, que lleva a
cabo operaciones adicionales cuando se accede a un objeto
(ver ejemplo operadores C++):
� CContar t ell número ú dde referencias. f i
� Cargar un objeto persistente en memoria.
� Bloquear el objeto cuando se accede a él (no modificación
concurrente)
concurrente).
� …
72

Proxy
� Estructura.
73

Proxy
� Participantes.
� Proxy.
� Mantiene una referencia que permite al proxy acceder al objeto real.
� Proporciona una interfaz igual que la del sujeto real.
� Controla el acceso al sujeto real, y puede ser responsable de crearlo y
borrarlo.
� Otras responsabilidades, dependen del tipo de proxy:
• Proxy Remoto: codifican las peticiones peticiones, y se las mandan al sujeto sujeto.
• Proxy virtual: Puede guardar información adicional sobre el sujeto, para
retardar el acceso al mismo.
• Proxy de protección: comprueba que el llamador tiene permiso para
realizar la petición petición.
� Subject.
� Define una interfaz común para el RealSubject y el Proxy, de tal
manera que el Proxy se puede usan en vez del RealSubject
RealSubject.
� RealSubject.
� Define el objeto real que el proxy representa.
�� Colaboraciones
Colaboraciones.
� El proxy redirige peticiones al sujeto real cuando sea necesario,
dependiendo del tipo de proxy.
74

Proxy
�� Consecuencias
Consecuencias.
� Introduce un nivel de indirección adicional, que tiene muchos
posibles usos:
�� UUn proxy remoto t puede d ocultar lt el l hhecho h dde que un objeto bj t reside id en
otro espacio de direcciones.
� Un proxy virtual puede realizar optimizaciones, como crear objetos
bajo demanda demanda.
� Tanto los proxies de protección, como las referencias inteligentes
permiten realizar tareas de mantenimiento adicionales cuando se
accede a un objeto objeto.
� Otra optimización: copy-on-write.
� Copiar un objeto grande puede ser costoso.
�� Si la copia no se modifica modifica, no hay necesidad de incurrir en dicho
gasto.
� El sujeto mantiene una cuenta de referencias, sólo cuando se hace
una operación que modifica el objeto objeto, se copia realmente (ej (ej.: : clase
String del ejemplo de operadores C++).
75

Proxy
�� Implementación
Implementación.
� Se pueden explotar las
siguientes características de
llos llenguajes: j
� Sobrecargar el operador de
acceso a miembros -> en
C++ C++.
class Image;
extern Image* LoadAnImageFile(const char*);
// external function
class ImagePtr {
public:
ImagePtr(const char* char imageFile);
virtual ~ImagePtr();
virtual Image* operator->();
virtual Image& operator*();
private:
Image* LoadImage();
private:
Image* Image _image; image;
const char* _imageFile;
};
ImagePtr::ImagePtr (const char* theImageFile) {
_imageFile = theImageFile;
_image = 0;
}
Image* Image ImagePtr::LoadImage () {
if (_image == 0) {
_image = LoadAnImageFile(_imageFile);
}
return _image;
}
76

Proxy
Image* Image ImagePtr::operator-> ImagePtr::operator () {
return LoadImage();
}
Image& ImagePtr::operator* () {
return t *LoadImage();
*L dI ()
}
ImagePtr image = ImagePtr("anImageFileName");
image->Draw(Point(50, 100));
// (image.operator->())->Draw(Point(50, 100))
� Sobrecargar “->” no funciona si necesitamos saber a qué operación se
llama: entonces hay que definir dichar operación en el proxy y redirigir la
llamada llamada.
� A veces no hace falta que el proxy conozca el tipo concreto del sujeto
real (si es suficiente con la interfaz de la clase abstracta Subject).
77

Proxy
Ejemplo: Un Proxy Virtual
class Graphic {
public:
virtual ~Graphic();
virtual void Draw(const Point& at) = 0;
virtual void HandleMouse(Event& event) = 0;
virtual const Point& GetExtent() = 0;
virtual void Load(istream& from) = 0;
virtual void Save(ostream& to) = 0;
protected: p
Graphic();
};
class Image : public Graphic {
public:
Image(const char* file); // loads image from a file
virtual ~Image();
private:
// ...
};
virtual void Draw(const Point& at);
virtual void HandleMouse(Event& event);
virtual const Point& GetExtent();
virtual void Load(istream& from);
virtual void Save(ostream& to);
78

Proxy
Ejemplo: Un Proxy Virtual
class ImageProxy : public Graphic { // la clase proxy
public:
ImageProxy(const char* imageFile);
virtual ~ImageProxy();
virtual i t l void id D Draw(const ( t Point& P i t& at); t)
virtual void HandleMouse(Event& event);
virtual const Point& GetExtent();
virtual void Load(istream& from);
virtual void Save(ostream& to);
protected:
Image* GetImage();
private: i t
};
Image* _image;
Point _extent;
char* c a _fileName; e a e;
79

Proxy
Ejemplo: Un Proxy Virtual
ImageProxy::ImageProxy (const char char* fileName) {
_fileName = strdup(fileName);
_extent = Point::Zero; // don't know extent yet
_image = 0;
}
Image* ImageProxy::GetImage() {
if (_image == 0) {
_image = new Image(_fileName);
}
return _image;
}
void ImageProxy::Save (ostream& to) {
to _extent >> _fileName;
}
const Point& ImageProxy::GetExtent () {
if (_extent ( t t == Point::Zero) P i t Z ) {
_extent = GetImage()->GetExtent();
}
return _extent;
}
void ImageProxy::Draw (const Point& at) {
GetImage()->Draw(at);
}
void ImageProxy::HandleMouse (Event& event) {
GetImage()->HandleMouse(event);
}
80

Proxy
Ejemplo: Un Proxy Virtual
class TextDocument {
public:
TextDocument();
void Insert(Graphic*);
// ...
};
TextDocument* text = new TextDocument;
// ...
text->Insert(new ImageProxy("anImageFileName"));
81

Ejercicio (Junio de 208)
�� SSea lla aplicación li ió dde pedidos did vista i t en ttemas anteriores:
t i

Ejercicio
� En el contexto de la aplicación anterior, supón
que sólo se puede acceder al disponible de una
cuenta de pago si se ha introducido una clave.
Utilizando patrones de diseño, implementa en
C++ un Proxy de Protección que asegure que se
accede al disponible de la cuenta sólo si la clave
es correcta (supón que la clave se pide por la
consola). La clave se almacena en el proxy, y
éste recuerda si ya se ha introducido
correctamente o no.

#include "stdafx.h"
#include
#include
using std::cout;
using std::string;
using std::cin;
class Cuenta
{
public:
virtual int obtenerDisponible () = 0;
};
class CuentaReal : public Cuenta
{
private:
public:
int disponible;
CuentaReal (int d ) : disponible (d) {}
int obtenerDisponible() {return disponible; }
Solución (1)
};
class ProxyCuenta: public Cuenta
{
private:
CuentaReal * cuenta;
string clave;
bool correcta;
bool intro;
public:
ProxyCuenta ( string psswd, psswd CuentaReal & c ) :
clave(psswd), cuenta(&c), intro(false), correcta(false) {}
int obtenerDisponible();
};

int ProxyCuenta::obtenerDisponible() {
if (correcta) return cuenta->obtenerDisponible();
else if (!intro) {
intro = true;
string cl;
cout > cl;
if (cl == clave) {
correcta = true;
return cuenta->obtenerDisponible();
}
else {
correcta = false;
cout

Adapter
� Propósito.
� Convierte el interfaz de una clase en otro que q espera p el cliente.
� El adapter permite trabajar juntas a clases que de otra forma no podrían por
tener interfaces incompatibles.
� También conocido como.
� Wrapper (envoltorio).
� Motivación.
�� A veces una clase de una biblioteca que ha sido diseñada para reutilizarse reutilizarse,
no puede hacerlo porque su interfaz no coincide con la interfaz específica
de dominio que requiere la aplicación.
�� Ej Ej.: : un editor de dibujo dibujo. Objetos gráficos gráficos, con una clase base abstracta
Shape.
� Queremos reutilizar una clase existente TextView para implementar TextShape
(quizá no tengamos el código fuente de TextView).
� Solución: Definir una clase TextShape que adapte el interfaz de TextView a
Shape.
� Se puede hacer de dos maneras:
• Adaptador de clase: Heredando el interfaz de Shape y la implementación de
TextView.
• Adaptador de objeto: Componiendo un objeto TextView dentro de un TextShape, 86e
implementando TextShape en términos de la interfaz de TextView.

Adapter
�Motivación.
� Adaptador p de objeto. j
87

Adapter
�Estructura.
�Adaptador p de clase.
88

Adapter
�Estructura.
�Adaptador p de objeto. j
89

Indice
� Introducción.
� Patrones de Creación.
� Patrones Estructurales.
�Patrones �Patrones de Comportamiento
Comportamiento.
�Iterator.
�Observer.
�Template Method.
�State.
�Strategy. gy
�Command.
�Chain �Chain of Responsibility.
Responsibility
� Conclusiones.
� Bibliografía.
90

Patrones de Comportamiento
�Tratan sobre algoritmos y la asignación de
responsabilidades p entre objetos. j
�Describen no sólo patrones de clases y
objetos objetos, sino patrones de comunicación
entre ellos.
�Caracterizan un flujo de control complejo,
difícil de seguir en tiempo de ejecución.
�Permiten que el diseñador se concentre
sólo ól en cómo ó iinterconectar t t objetos.
bj t

Iterator
�� Propósito Propósito.
� Proporciona un medio de acceder a los elementos de un
contenedor secuencialmente sin exponer su representación
interna interna.
� También Conocido Como.
� Cursor.
� Motivación.
� Un contenedor (p.ej.: una lista) debe proporcionar un medio de
navegar g sus datos secuencialmente sin exponer p su
representación interna.
� Se debe poder atravesar la lista de varias maneras,
dependiendo de lo que se quiera hacer.
� Probablemente no interesa añadir a la lista operaciones para
realizar los diferentes recorridos.
� Puede necesitarse hacer más de un recorrido simultáneamente.
� Dar la responsabilidad de acceder y recorrer el objeto lista a un
objeto Iterator.
92

Iterator
� Motivación.
list
List
+ Count()
+ Append(Element)
+ Remove(Element)
1 *
ListIterator
- index
+ First()
+Next() + Next()
+ IsDone()
+ CurrentItem()
� Antes de instanciar el ListIterator, se ha de proporcionar la lista.
� Una vez que se tiene la instancia, se puede acceder a los
elementos de la lista secuencialmente
secuencialmente.
� Separar el mecanismo de recorrido del objeto lista, nos permite
definir iteradores que implementen distintas estrategias.
93

Iterator
� Motivación.
� El iterador y la lista están acoplados: el cliente sabe que lo que se está recorriendo es una lista.
� Es mejor poder cambiar el contenedor sin tener que cambiar el código cliente: iteración
polimórfica.
skiplist
1
AbstractList
+CreateIterator()
+ Count()
+ AAppend(Element) d(El t)
+ Remove(Element)
…
Cli Client t
1 list
*
Iterator
+ First()
+ Next()
+ IsDone()
+ CurrentItem()
SkipList List
ListIterator SkipListIterator
� Podemos hacer responsables a las listas de crear sus propios iteradores, mediante un factory
method (CreateIterator).
� Se puede definir algoritmos generales que usan un iterador genérico (en C++: “for_each”, “find_if”, 94
“count”, etc)
*

Iterator
� Aplicabilidad. Usar el patrón :
�� para acceder al contenido de un contenedor sin exponer su
representación interna.
� para permitir varios recorridos sobre contenedores.
� para proporcionar una interfaz uniforme para recorres distintos tipos
de contenedores (esto es, permitir la iteración polimórfica).
� Estructura. Iterator
Aggregate
+CreateIterator ()
ConcreteAggregate
+CreateIterator ()
return new ConcreteIterator (this)
Client
+First ()
+Next ()
+IsDone IsDone ()
+CurrentItem ()
ConcreteIterator
95

Iterator
�� Participantes
Participantes.
� Iterator.
� Define una interfaz para recorrer los elementos y acceder a ellos.
� ConcreteIterator.
� Implementa la interfaz Iterator.
� Mantiene la posición actual en el recorrido del agregado.
� Aggregate.
� Define una interfaz para crear un objeto Iterator.
� ConcreteAggregate.
� Implementa una interfaz de creación del Iterator para devolver una
instancia del ConcreteIterator apropiado.
� Colaboraciones.
� Un ConcreteIterator sabe cuál es el objeto actual del agregado y
puede calcular el objeto siguiente del recorrido.
96

Iterator
�� Consecuencias
Consecuencias.
� Permite variaciones en el recorrido de un agregado.
� Los iteradores simplifican la interfaz del contenedor.
� Se puede hacer más de un recorrido a la vez sobre un
agregado.
�� Implementación.
� ¿Quién controla la iteración?.
� El cliente controla la iteración: iterador externo.
�� El iterador controla la iteración: iterador interno. interno
� ¿Quién define el algoritmo de recorrido?
� El iterador.
�� El agregado, d y el l it iterador d sólo ól almacena l el l estado t d dde lla
iteración. A este tipo de iterador se le llama cursor.
� ¿Cómo de robusto es el iterador?
�� Iterador robusto: Las inserciones y borrados no interfieren en el
recorrido (y se hace sin copiar el agregado).
97

Iterator
�� IImplementación. l t ió
� Operaciones adicionales del iterador.
�� Por ejemplo, iteradores ordenados podrían tener una operación
Previous. Otras como SkipTo.
� Usar iteradores polimórficos en C++.
�� Los iteradores polimórficos han de crearse dinámicamente por un
método de fabricación.
� El cliente además es responsable de borrarlos (propenso a
errores) errores).
� Iteradores para Composites.
� Los iteradores externos pueden ser complicados de implementar
en estructuras t t recursivas. i
� NullIterators.
� Es un iterador degenerado g qque ayuda y a manejar j condiciones
límite.
98

Iterator
Ejemplo
11. Interfaces de la lista y el iterador iterador.
template
class List {
public:
List(long size = DEFAULT_LIST_CAPACITY);
long Count() const;
Item& Get(long index) const;
// ...
};
template
class Iterator {
public:
virtual void First() = 0;
virtual void Next() = 0;
virtual bool IsDone() const = 0;
virtual Item CurrentItem() const = 0;
protected:
Iterator();
};
99

Iterator
Ejemplo
22. Implementaciones de las subclases del iterador iterador.
template
class ListIterator : public Iterator {
public:
ListIterator(const List* aList) _list(aList), _current(0) {}
virtual void First() {_current = 0;}
virtual void Next() {_current++;}
virtual bool IsDone() const {return _current >= _list->Count(); }
virtual Item CurrentItem() const;
private:
const List* List _list; list;
long _current;
};
template
Item ListIterator::CurrentItem () const {
if (IsDone()) throw IteratorOutOfBounds;
return _list->Get(_current);
}
// Se puede implementar un ReverseListIterator, con First
// posicionando el iterador al final de la lista, y Next decrementando
100

Iterator
Ejemplo
33. UUso ddel l iiterador. d
void PrintEmployees (Iterator& i) {
for (i.First(); ( (); !i.IsDone(); (); i.Next()) ()) {
i.CurrentItem()->Print();
}
}
List* employees;
// ...
ListIterator forward(employees);
ReverseListIterator backward(employees);
PrintEmployees(forward);
PrintEmployees(backward);
101

Iterator
Ejemplo
4. Evitar ajustarse j a una implementación p
concreta de la lista.
� Supongamos que tenemos SkipList y SkipListIterator.
� Se puede introducir un AbstractList para estandarizar la interfaz de la lista
(List ( y SkipList p son subclases de AbstractList). )
� Para permitir iteración polimórfica, AbstractList define un factory method
CreateIterator.
template
class AbstractList {
public:
virtual Iterator* CreateIterator() const = 0;
// ...
};
template
Iterator* List::CreateIterator () const {
return new ListIterator(this);
}
// we know only y that we have an AbstractList
AbstractList* employees;
// ...
Iterator* iterator = employees->CreateIterator();
Pi PrintEmployees(*iterator);
tE l (*it t )
delete iterator;
102

Iterator
Ejemplo
5. Asegurarse g de que q los iteradores se borran.
� Crear un IteratorPtr, que actua de Proxy para un Iterator.
� Se ocupa de borrar el Iterator cuando se sale de ámbito.
template
class IteratorPtr {
public:
IteratorPtr(Iterator* i): _i(i) i(i) { }
~IteratorPtr() { delete _i; }
Iterator* operator->() { return _i; }
Iterator& operator*() p () { return *_i; _ }
private:
// disallow copy and assignment to avoid
// multiple deletions of _i:
IteratorPtr(const IteratorPtr&);
IteratorPtr& operator=(const IteratorPtr&);
private:
Iterator* _i; _
};
AbstractList* employees;
// ...
IIteratorPtr P E l *
iterator(employees->CreateIterator());
PrintEmployees(*iterator);
103

Iterator
Ejemplo
6. Un iterador interno.
� El iterador controla la iteración, y aplica una operación a cada elemento.
� La operación se puede configurar:
template
class ListTraverser {
public:
�� Pasando un puntero a una función función, o a un objeto función función.
� Mediante subclasificación.
ListTraverser(List* aList):_iterator(aList) { };
bool Traverse();
protected:
virtual bool ProcessItem(const Item&) = 0;
private:
ListIterator _iterator;
};
template
bool ListTraverser::Traverse () {
bool result = false;
for ( _iterator.First(); iterator First(); ! !_iterator.IsDone();_iterator.Next()) iterator IsDone(); iterator Next()) {
result = ProcessItem(_iterator.CurrentItem());
if (result == false) break;
}
return result;
}
104

Iterator
Ejemplo
66. UUn iiterador d iinterno
� Imprimir los n primeros empleados de una lista.
class PrintNEmployees : public ListTraverser {
public:
PrintNEmployees(List* aList, int n) :
ListTraverser(aList),
p y ( )
_total(n), _count(0) { }
protected:
bool ProcessItem(Employee* const&);
private:
}; }
int _total;
int _count;
bool PrintNEmployees::ProcessItem (Employee* const& e) {
_count++;
e e->Print(); >Print();
return _count < _total;
}
105

Iterator
Ejemplo
66. UUn it iterador d iinterno t
� Imprimir los n primeros empleados de una lista.
List* List Employee employees;
// ...
PrintNEmployees pa(employees, 10);
pa.Traverse();
� Comparación con un iterador externo:
ListIterator i(employees);
int count = 0;
for (i.First(); !i.IsDone(); i.Next()) {
count++;
i.CurrentItem()->Print();
if (count >= 10) break;
}
106

Iterator
Ejemplo
66. UUn iiterador d iinterno
� Pueden encapsular distintos tipos de operaciones.
template
class FilteringListTraverser {
public:
FilteringListTraverser(List* aList);
bool Traverse(); ()
protected:
virtual bool ProcessItem(const Item&) = 0;
virtual bool TestItem(const ( Item&) ) = 0;
private:
ListIterator _iterator;
};
template
void FilteringListTraverser::Traverse () {
bool result = false;
for (_iterator.First();!_iterator.IsDone();_iterator.Next()) (_ () _ () _ ()) {
if (TestItem(_iterator.CurrentItem())) {
result = ProcessItem(_iterator.CurrentItem());
if (result == false) break;
}
}
return result;
}
107

Observer
�� PPropósito. ó it
� Define una dependencia de uno-a-muchos entre objetos, de
forma que q cuando un objeto j cambie de estado se notifique q y
actualicen automáticamente todos los objetos que dependen
de él.
�� También conocido como. como
� Dependents, Publish-Subscribe
� Motivación.
� Mantener consistencia entre objetos relacionados.
� No queremos obtener dicha consistencia aumentando el
acoplamiento entre clases. clases
� Ej.: separación de la presentación en GUI de los datos de
aplicación subyacente.
108

Observer
� Motivación.
C
D
B
A
A B C D
X 60 20 15 5
Y 40 25 15 20
Z 10 10 20 60
Modelo
A: 40%
B: 25%
CC: 15%
D: 20%
40
30
20
10
0
A B C D
109

Observer
� Aplicabilidad.
� Cuando una abstracción tiene dos aspectos y uno depende del otro.
� Cuando un cambio en un objeto requiere cambiar otros, y no sabemos
cuántos hay yqque
cambiar.
� Cuando un objeto debería ser capaz de notificar a otros sin hacer
suposiciones sobre quiénes son dichos objetos (esto es, no queremos
que los objetos estén fuertemente acoplados).
acoplados)
� Estructura.
observers
Subject Observer
00..1 1
1 1..* *
+Attach (Observer)
+Detach (Observer)
+Notify ()
ConcreteSubject
- subjectState
+GetState ()
+SetState ()
0..1
forall o in observers
o.Update()
subject
+Update()
ConcreteObserver
- observerState
+Update ()
return subjectState observerState=
subject->GetState()
110

Observer
� Participantes.
�� SSubject. bj t
� Conoce a sus observadores, que pueden ser un número arbitrario.
� Proporciona un interfaz para añadir y quitar objetos Observer.
�� Ob Observer.
� Define un interfaz de actualización para los objetos que deben ser
notificados sobre cambios en un sujeto.
�� ConcreteSubject
ConcreteSubject.
� Almacena estado de interés para ConcreteObservers.
� Manda notificaciones a sus observadores cuando su estado cambia.
�� ConcreteObserver
ConcreteObserver.
� Mantiene una referencia a objetos ConcreteSubject.
� Almacena el estado que debe ser consistente con el del sujeto.
�� Implementa el interfaz de actualización del Observer para mantener su
estado consistente con el del sujeto.
111

Observer
� Colaboraciones.
� El ConcreteSubject notifica a sus observadores cada vez que se
produce un cambio que pudiera hacer que el estado de estos fuese
inconsistente con el suyo. y
� Después de ser notificado del cambio, un ConcreteObserver puede
pedir al subject más información.
SetState()
:ConcreteSubject
Notify()
Update()
GetState()
Update()
GetState()
barDiagram
:ConcreteObserver
sectorDiagram
:ConcreteObserver
112

Observer
�� Consecuencias
Consecuencias.
� Permite modificar los sujetos y observadores de manera
independiente.
�� SSe pueden d reutilizar tili llos sujetos j t sin i sus observadores b d y
viceversa.
� Se pueden añadir observadores sin modificar el sujeto u otros
observadores
observadores.
� Acoplamiento abstracto entre sujeto y observador. El sujeto no
conoce la clase concreta de ningún observador (el acoplamiento
es mínimo) mínimo).
� Capacidad de comunicación mediante difusión. La notificación
del sujeto se envía automáticamente a todos los observadores
suscritos. Se pueden p añadir y quitar q observadores en cualquier q
momento.
� Actualizaciones inesperadas. Una operación aparentemente
inofensiva sobre el sujeto puede desencadenar una cascada de
cambios bi en llos observadores.
b d
113

Observer
�� Implementación
Implementación.
� Correspondencia entre sujetos y observadores.
� Que el sujeto guarde referencias a los observadores a los que debe
notificar notificar.
� Observar más de un sujeto.
� Ej.: una hoja de cálculo puede observar más de un origen de datos.
�� Extender la interfaz de actualización para que el observador sepa
qué sujeto se ha actualizado (quizá simplemente el sujeto se pase
a sí mismo como parámetro del update()).
� ¿Quién ¿Q dispara p la actualización?
� Las operaciones que cambien el estado del sujeto llaman a Notify().
• Ventaja: los clientes no tienen que hacer nada.
• Inconveniente: no es óptimo si hay varios cambios de estado seguidos.
� Los clientes llaman a Notify():
• Ventaja: se puede optimizar llamando a notify sólo después de varios
cambios.
• Inconveniente: los clientes tienen la responsabilidad añadida de llamar
a Notify().
114

Observer
� Implementación.
�Referencias perdidas a sujetos borrados.
� Una manera de evitarlo es notificar a los observadores
cuando se borra un sujeto.
�Asegurarse �Asegurarse de que el estado del Sujeto sea consistente
consigo mismo antes de la notificación:
� Hay que tener cuidado con las operaciones heredadas.
void MySubject::Operation (int newValue) {
BaseClassSubject::Operation(newValue);
// trigger notification
_myInstVar += newValue;
// update subclass state (too late!)
}
115

Observer
�� Implementación
Implementación.
� Evitar protocolos específicos del obervador: los modelos
push y pull.
� Las implementaciones de observer suelen hacer que el sujeto
envie información adicional como parámetro de Update().
� Dos extremos:
• Modelo Push: el sujeto envía información detalla del cambio cambio, quieran
los observadores o no.
Inconveniente: observadores menos reutilizables.
• Modelo Pull: el sujeto no envía nada, y los observadores piden
ddespués é llos ddetalles t ll explícitamente.
lí it t
Inconveniente: puede ser poco eficiente.
� Especificar las modificaciones de interés explícitamente:
�� Mejorar la eficiencia haciendo que los observadores registren
solo aquellos eventos que les interesen.
� Los observadores se subscriben a aspectos del sujeto.
116

Observer
� Implementación.
�� Encapsular la semántica de las operaciones complejas complejas.
Subject
+Attach (Observer o)
+Detach (Observer)
+Notify ()
chman->Notify()
chman >Notify()
� Si la relación de dependencia entre sujetos y observadores es compleja, puede ser
necesario un objeto intermedio para la gestión de cambios (ChangeManager).
� Minimizar el trabajo j necesario ppara qque los observadores reflejen j los cambios en el
sujeto.
� Ej.: si varios sujetos han de cambiarse, asegurarse de que se notifique a los
observadores sólo después del cambio en el último sujeto.
chman->Registar(this,o)
forall s in subjects:
forall o in observers:
o->Update(s)
subjects
0..*
chman
1
ChangeManager
Subject-Observer mapping
+Register (Subject,Observer)
+Unregister (Subject,Observer)
+Notify ()
observers
1..*
SimpleChangeManager DAGChangeManager
+Register (Subject,Observer)
+Unregister (Subject,Observer)
+Notify ()
+Register (Subject,Observer)
+Unregister (Subject,Observer)
+Notify ()
Observer
+Update(Subject)
Marcar todos los observers
a actualizar.
Actualizar los observers
marcados.
117

Observer
Ejemplo
class Subject;
class Observer {
public:
virtual ~ Observer(); ()
virtual void Update (Subject*
theChangedSubject) = 0;
// soporte de múltiples subjects
protected:
Observer();
};
class Subject {
public:
virtual ~Subject(); j ()
virtual void Attach(Observer*);
virtual void Detach(Observer*);
virtual void Notify();
protected:
Subject();
private:
List *_observers;
_
};
void Subject::Attach (Observer* o) {
_observers->Append(o);
}
void Subject::Detach (Observer* o) {
_observers->Remove(o);
}
void Subject::Notify () {
ListIterator i(_observers);
for (i.First(); !i.IsDone(); i.Next()) {
ii.CurrentItem()->Update(this); CurrentItem() >Update(this);
}
118
}

Observer
Ejemplo
class ClockTimer : public Subject { class DigitalClock: public Widget, public
// Concrete subject
Observer {
public:
public:
ClockTimer(); ()
DigitalClock(ClockTimer*);
virtual int GetHour();
virtual it l~DigitalClock(); DiitlClk() virtual int GetMinute();
virtual void Update(Subject*);
virtual int GetSecond();
// overrides Observer operation
void Tick();
virtual void Draw();
};
// overrides Widget operation;
// defines how to draw the digital clock
void ClockTimer::Tick () {
private:
// update internal time-keeping state
Cl ClockTimer* kTi * _subject; bj t
// ...
};
Notify();
DigitalClock::DigitalClock (ClockTimer* s) {
} _subject bj t = s;
_subject->Attach(this);
}
DigitalClock::~DigitalClock DigitalClock:: DigitalClock () {
_subject->Detach(this);
}
119

Observer
Ejemplo
void DigitalClock::Update (Subject* theChangedSubject) {
if (theChangedSubject == _subject) Draw();
}
void DigitalClock::Draw () {
int hour = _subject->GetHour(); // get the new values from the subject
}
int minute = _subject->GetMinute();
// etc.
// draw the digital clock
class AnalogClock : public Widget Widget, public Observer {
public:
AnalogClock(ClockTimer*);
virtual void Update(Subject*);
virtual void Draw();
// ...
};
ClockTimer* timer = new ClockTimer;
AnalogClock* analogClock = new AnalogClock(timer);
DigitalClock* digitalClock = new DigitalClock(timer);
120

Observer
Usos Conocidos
�� Sistemas de de eventos en Java (observer=listener)
(observer listener)
� AWT/Swing
� Javabeans
� MVC en el sistema de ventanas de Smalltalk
� Model=Subject
�� View=Observer
� Controller=Cualquier objeto que cambie el estado de Subject
� MVC en entornos web (J2EE)
� Model=EJB
� View=JSP
�� Controller=servlet
Controller servlet
121

Template Method
� Propósito. p
� Definir el esqueleto de un algoritmo, delegando en las subclases
alguno de sus pasos.
�� Permite que las subclases cambien pasos de un algoritmo sin cambiar
su estructura.
� Motivación.
� Ej.: MFCs, abrir un fichero.
Document
docs
Application pp
1 1..* *
+Abrir()
+Cerrar()
+Guardar()
+DoRead() D R d()
MyDocument
y
+DoRead()
return MyDocument
+AddDocument()
+OpenDocument()
+DoCreateDocument()
+CanOpenDocument()
+AboutToOpenDocument()
MyApplication
+DoCreateDocument()
+CanOpenDocument()
+AboutToOpenDocument()
void Application::OpenDocument (const char* name) {
if (!CanOpenDocument(name)) {
// cannot handle this document
return;
}
Document* doc = DoCreateDocument();
if (doc) {
_docs->AddDocument(doc);
AboutToOpenDocument(doc);
doc->Open();
doc doc->DoRead();
>DoRead();
}
122
}

Template Method
� Aplicabilidad.
� Para implementar las partes de un algoritmo que no cambian,
y dejar que las subclases implementen el comportamiento
que puede variar variar.
� Cuando el comportamiento repetido de varias subclases
debería factorizarse y localizarse en una clase común, para
evitar código duplicado.
� Para controlar las extensiones de las subclases.
�� EEstructura. t t
ClaseAbstracta
+TemplateMethod()
+PrimitiveOperation1() …
+PrimitiveOperation2()
PrimitiveOperation1()
+…
…
PrimitiveOperation2()
ConcreteClass
+PrimitiveOperation1()
+PrimitiveOperation2()
123

State
� Propósito.
�� Permitir que un objeto modifique su comportamiento cada vez que cambie su
estado interno.
� Parecerá que cambia la clase del objeto.
� También conocido como.
� Objets for state (estados como objetos).
� Motivación.
� TCPConnection para p representar p una conexión de red.
� Puede estar en distintos estados: establecida, escuchando y cerrada.
� El efecto de cada petición sobre cada objeto depende del estado en el que está.
124

State
�Estructura.
125

Strategy
� Propósito.
� Define una familia de algoritmos, encapsula cada uno de ellos, y los hace
intercambiables.
� Permite que un algoritmo varíe independientemente de los clientes que los usan.
� También conocido como.
� Policy (política).
�� Motivación
Motivación.
� Ej.: Algoritmos para dividir en líneas un flujo de texto.
� Clases que encapsulen los distintos algoritmos de división. Un algoritmo así
encapsulado se denomina estrategia estrategia.
126

Strategy
�Estructura.
127

Command
� Propósito.
�� Encapsula peticiones a objetos objetos.
� Permite parametrizar a los clientes con diferentes peticiones, hacer
cola o llevar un registro de peticiones, así como deshacer las
peticiones peticiones.
� También conocido como.
� Action, Transaction.
� MMotivación. ti ió
� Framework gráfico tipo MFC. Peticiones de los distintos widgets
encapsuladas como objetos.
128

Command
�� MMotivación. ti ió
129

Command
�� EEstructura. t t
130

Chain of Resposibility
� Propósito.
� Evita acoplar el emisor de una petición a su receptor, dando a más
de un objeto la posibilidad de responder a la petición.
�� Encadena los objetos receptores y pasa la petición a través de la
cadena hasta que es procesada por algún objeto.
� Motivación.
� Ej.: ayuda sensible al contexto en una GUI.
� Si no existe ayuda para una parte de la interfaz, se muestra ayuda
para p una pparte más ggeneral.
131

Chain of Resposibility
�Motivación.
132

Chain of Resposibility
�Estructura.
133

Indice
�� IIntroducción. t d ió
� Patrones de Creación.
�� Patrones Estructurales.
Estructurales
� Patrones de Comportamiento.
�Conclusiones
�Conclusiones.
� Bibliografía.
134

Conclusiones
�� Los patrones de diseño capturan el conocimiento que
tienen los expertos a la hora de diseñar.
� Los patrones ayudan a generar software “maleable”
(software que soporta y facilita el cambio, la reutilización
y la mejora) mejora).
� Los patrones de diseño son guías, no reglas rigurosas.
� Cada patrón describe la solución a problemas que se
repiten una y orta vez en nuestro entorno entorno, de forma que
se puede usar esa solución todas las veces que haga
falta.
135

Indice
�� IIntroducción. t d ió
� Patrones de Creación.
�� Patrones Estructurales.
Estructurales
� Patrones de Comportamiento.
�� Conclusiones
Conclusiones.
�Bibliografía.
136

Bibliografía
� “D “Design i patterns, tt elements l t of f reusable bl object- bj t
oriented software”. Gamma, Helm, Jonhnson,
Vlissides Vlissides. Addison Wesley, Wesley 1995 (traducido al
español en 2003).
� “Applying UML and Patterns. An introduction to
Object Object-Oriented Oriented Analysis and Design and
Iterative Development. 3rd Edition.” Craig
Larman Larman. Prentice Hall Hall.2005. 2005
�� http://hillside http://hillside.net/
net/
137