1. Diseño de Software
Dr. Amos Sorgen
Agosto de 2011 slide 1
Templates
Autor Dr Amos Sorgen // Editor Mg Ing Rolando Titiosky
Basado en: Ing de Software (Ian Sommersville); UML y Patrones
(Craig Larman)

2. Diseño de software
Dr. Amos Sorgen
2
Agosto 2011
Function Templates
• Nos permite escribir funciones genéricas que pueden ser
usadas con varios tipos de datos.
• Sin templates, se tendrían que rescribir muchas funciones
(y clases).
• Ejemplo: una función que retorna el máximo de dos
valores.
int max(int x, int y) { return (x < y) ? y : x; }
float max(float x, float y) { return (x < y) ? y : x; }
template <typename T> T max(T x, T y)
{ return (x < y) ? y : x; }
Esta funcion funciona con cualquier tipo que se pueda
comparar con el “operador <“
Funciona hasta con una clase desconocida por el
compilador, si se implementa el “operador <“

3. Diseño de Software
Dr. Amos Sorgen
Agosto de 2010 slide 3
Patrones de Diseño OO

4. Diseño de software
Dr. Amos Sorgen
4
Agosto 2011
Patrones de diseño
• Los patrones de diseño son la base
para solucionar problemas de diseño
comunes a distintas aplicaciones.
• Proveen una solución estándar para un
problema común de diseño
• Se presentan en formas distintas
porque lo que varia es el dominio del
problema y por lo tanto las clases que
entran en juego

5. Diseño de software
Dr. Amos Sorgen
5
Agosto 2011
Ejemplo de problemas similares
• Modelar en un sistema S que tiene Y-s y z-s. A su vez los Y-s
pueden recursivamente incluir Y-s y z-s (las z-s no pueden
incluir a nadie) formando un arbol cuyas ramas son las Y-s y
cuyas hojas son las z-s.
• Hay muchas actividades comunes a las Y-s y a las z-s que
cuando se aplican a las Y-s se aplican recursivamente:
– Delete()
– Copy()
– Display()
– Move()
– …
• Hay actividades que solo aplican a las Y-s
– Add(Y or z)
– GetNextChild(Y or z)
• Ejemplos:
– S = sistema operativo Y = directorio z= archivos
– S = sistema grafico Y = gráficos complejos z = elementos
geométricos
– S = un sistema de ventanas Y = ventanas z = controles

6. Diseño de software
Dr. Amos Sorgen
6
Agosto 2011
Se Necesita…
• Componer objetos en estructuras de
árbol para representar jerarquías parte-
todo
• Y Que permita tratar a las “hojas” y a
las “ramas” de manera uniforme
(composición recursiva).

7. Diseño de software
Dr. Amos Sorgen
7
Agosto 2011
Solucion particular

8. Diseño de software
Dr. Amos Sorgen
8
Agosto 2011
Solución general: Composite Patern

9. Diseño de software
Dr. Amos Sorgen
9
Agosto 2011
Descripción de los patrones
• Nombre del patrón: nombre estándar del patrón por el cual
será reconocido en la comunidad (normalmente se expresan en
inglés).
• Clasificación del patrón: creacional, estructural o de
comportamiento.
• Intención: ¿Qué problema pretende resolver el patrón?
• Motivación: Escenario de ejemplo para la aplicación del patrón.
• Aplicabilidad: Usos comunes y criterios de aplicabilidad del
patrón.
• Estructura: Diagramas de clases oportunos para describir las
clases que intervienen en el patrón.
• Consecuencias: Consecuencias positivas y negativas en el
diseño derivadas de la aplicación del patrón.
• Implementación: Técnicas o comentarios oportunos de cara a
la implementación del patrón.
• Código de ejemplo: Código fuente ejemplo de implementación
del patrón.
• Usos conocidos: Ejemplos de sistemas reales que usan el
patrón.

10. Diseño de software
Dr. Amos Sorgen
10
Agosto 2011
Gang of Four
La 'Banda de los cuatro',
• Es el nombre con el que se conoce comúnmente a
los autores del libro Design Patterns.
– Erich Gamma, Richard Helm, Ralph Johson, John Vlissides
• Pero se usa también como nombre genérico para
los 23 patrones que aparecen en ese libro
Patrones creacionales: Se aplican cuando hay
creación de objetos
Patrones estructurales: Se aplican cuando hay
composición de objetos
Patrones conductuales: Se aplican cuando objetos
interactúan

11. Diseño de software
Dr. Amos Sorgen
11
Agosto 2011
GoF - Patrones
Creacionales
• Absract Factory - Fábrica Absracta
Crea la instancia de la clase “hija” que corresponde
al contexto (ej. BotónWindows o un BotónLinux )
• Factory Method – Metodo de fabrica
Delega toda la creación de la instancia a la subclase.
• Builder - Constructor
Construye objetos complicados usando métodos en
las subclases
• Prototype - Prototipo
Crea una nueva instancia, copiando un prototipo
• Singleton
Una clase de las que sólo una sola instancia puede
existir

12. Diseño de software
Dr. Amos Sorgen
12
Agosto 2011
GoF - Estructurales
• Adapter - Adaptador
Adapta interfaces de diferentes clases para ser usadas por una
unica.
• Bridge - Puente
Crea un puente entre la verdadera clase y la clase como es
usada por otras clases
• Composite - Compuesto
Una estructura de árbol de objetos simples y compuestos
• Decorator - Decorador
Añade funcionalidades a los objetos de forma dinámica (run
time)
• Facade - Fachada
Una clase única que provee una interfase simplificada a todo un
subsistema
• Flyweight - Peso mosca
Permite compartir memoria entre objetos similares.
• Proxy - Apoderado
Un objeto que representa otro objeto pero que consume
muchos menos recursos

13. Diseño de software
Dr. Amos Sorgen
13
Agosto 2011
GoF - de comportamiento - 1
• Chain of Responsibilities - Cadena de
Responsabilidades
Una manera de pasar un pedido, en una cadena de
objetos hasta que se encuentre aquel que pueda
cumplirlo.
• Command - Comando
Encapsula la petición de un comando en un objeto que
puede ser guardado, trasmitido, etc.
• Interpreter - Intérprete
Interpreta frases de un lenguage.
• Iterator - Itereador
Accede secuencialmente a los elementos de una
colección
• Mediator - Mediador
Simplifica la comunicación entre las clases
• Memento - Recuerdo
Captura y restaura si es necesario el estado de un objeto

14. Diseño de software
Dr. Amos Sorgen
14
Agosto 2011
GoF - comportamiento – 2
• Observer - Observador
Una forma de notificar un cambio en un objeto a otros objetos
• State - Estado
Altera el comportamiento de un objeto cuando su estado
cambia
• Strategy - Estrategia
Encapsula un algoritmo dentro de un objeto. De esta forma se
puede seleccionar que algoritmo correr en tiempo de ejecucion.
• Template Method - Plantilla Método
Aplaza la implementación concreta de un algoritmo a una
subclase
• Visitor - Visitante
Se usa para introducir definir nuevas funcionalidades a una
clase sin necesidad de cambiarla.

15. Diseño de software
Dr. Amos Sorgen
15
Agosto 2011
Otra categorización de los Patrones
de diseño – 1
• Patrones de descomposición estructural
• Se aplican cuando se diseñan subsistemas y componentes complejos usando
módulos que cooperan unos con otros
• Ejemplo whole-part
• Patrones de organización de trabajo
• Se aplican cuando componentes colaboran juntos para resolver un problema complejo
• Ejemplo: master-slave
• Patrones de acceso de control
• Se aplican cuando hay que “cuidar” y “controlar” el acceso a servicios y componentes
• Ejemplo: proxy
• Patrones de administración
• Se aplican cuando hay que manejar colecciones homogéneas de objetos, servicios y
componentes en su totalidad.
• Ejemplo: command processor, view handler
• Patrones de comunicación
• Se aplican cuando hay que organizar comunicación entre componentes
• Ejemplo: forward-receiver, dispatcher-server, publisher-subscriber

16. Diseño de software
Dr. Amos Sorgen
16
Agosto 2011
Patrones populares
• Composite
• Singleton
• Factory
• Abstract factory (Factory method)
• Adapter
• Façade
• Observer
• Strategy
• State
• Decorator
• Prototype
• Proxy
• Chain of responsibility
• Command
• Iterator
• Mediator

17. Diseño de software
Dr. Amos Sorgen
17
Agosto 2011
Singleton
Problema: Se quiere
asegurar que una
clase tiene una
sola instancia
Ejemplo: Un sistema
que administra los
recursos humanos
de una empresa
necesite que no
haya mas que un
unico objeto
“presidente”
Generalización: “Pool
Object”
Class A {
Private
static A* The_a;
… Otros datos privados
… Otros metodos privados
Public
A() {
If (~The_a) The_a = make_a();
return A& The_a;
}
… otros datos publicos
… otros metodos publicos
}
A* A::The_a = NULL;

18. Diseño de software
Dr. Amos Sorgen
18
Agosto 2011
Factory
Problema: Se quiere tratar homogéneamente la
creación y subsecuente manipulación de
objetos que responden a un mismo concepto
pero que tienen distinto comportamiento en
distintas circunstancias
Ejemplo: Manipulación de elementos de IU bajo
distintos sistemas operativos.
Solución: Se genera una herencia de “factories”
paralela a la herencia de los objetos.
Para ello se crea el objeto (en el ejemple de
“WidgetFactory”) de acuerdo a la clase
especifica que dictan las circunstancias

19. Diseño de software
Dr. Amos Sorgen
Factory

20. Diseño de software
Dr. Amos Sorgen
20
Agosto 2011
Abstract Factory

21. Diseño de software
Dr. Amos Sorgen
21
Agosto 2011
Adapter
Problema: Proporcionar una interfaz
estable para clases que dan los
mismos servicios pero con distintas
interfaces
Ejemplo: Agregar en una librería grafica
un elemento que pertenece a otra
Solución: Estandarizar las interfaces
originales, mediante un objeto adaptador
intermedio

22. Diseño de software
Dr. Amos Sorgen
22
Agosto 2011
Adapter - Ejemplo

23. Diseño de software
Dr. Amos Sorgen
23
Agosto 2011
Facade
Problema: Se tiene
una biblioteca de
clases que dan
muchos servicios
con muchos
métodos y se
quiere
suministrar una
interfaz unificada
y sencilla para
los usuarios de la
biblioteca
Ejemplo:

24. Diseño de software
Dr. Amos Sorgen
24
Agosto 2011
Facade Ejemplo

25. Diseño de software
Dr. Amos Sorgen
25
Agosto 2011
Facade - Solución

26. Diseño de software
Dr. Amos Sorgen
26
Agosto 2011
Observer
Problema: Se quiere que, cuando el
objeto A cambie su estado, los objetos
X, Y, Z sean notificados y se actualicen
de acuerdo.
Solución: A tiene una lista de objetos
“observadores” que están interesados
en sus cambios. Hay un mecanismo de
“registrarse como observador”

27. Diseño de software
Dr. Amos Sorgen
27
Agosto 2011
Observer - Ejemplo

28. Diseño de software
Dr. Amos Sorgen
28
Agosto 2011
Strategy
Problema: Aplicar distintas estrategias de acuerdo a la situación en
tiempo de ejecución.
Ejemplo: La forma de validar los datos entrantes es función del tipo
de datos, la fuente de los datos, u otros factores de
discriminación.
Solución: Definir cada estrategia como una clase independiente.
De acuerdo al contexto se crea la clase concreta que
corresponde y en su creación se aplica la estrategia pertinente.

29. Diseño de software
Dr. Amos Sorgen
29
Agosto 2011
State
Problema: Se quiere encapsular (abstraer) las
operaciones que dependan del estado de un
objeto.
Ejemplo: Para una clase “carita” , los estados
serían
- Triste
- Serio
- Contento
Y la operación que depende del estado sería -
“dibujar”

30. Diseño de software
Dr. Amos Sorgen
30
Agosto 2011
State – Cambios de estado
enfadarse
alegrarse
alegrarse
Cambios de ánimo
Cara EstadoCara
v: EstadoCara
alegrar
enfadar
pintar
…
alegrar
enfadar
pintar
…
Triste
alegrar
enfadar
pintar
…
Contenta
alegrar
enfadar
pintar
…
Seria
alegrar
enfadar
pintar
…
Cara:alegrar
{
v.alegrar
}

31. Diseño de software
Dr. Amos Sorgen
31
Agosto 2011
Decorator
Problema: Se quiere añadir funcionalidad (distinta) a toda una serie
de clases heredadas
Ejemplo: Tenemos una super-clase Ventana y queremos añadirle
funcionalidad para que se dibuje un alrededor de todos los tipos
de ventanas.
Solución: Se crea una clase “XX_decorado” que hereda de la super-
clase y al mismo tiempo la contiene. De forma que accesando a
una funcion de “XX_decorado”, se accesa a la misma función de
XX y a los agregados

32. Diseño de software
Dr. Amos Sorgen
32
Agosto 2011
Prototype
• Problema: Sin saber que sub-clase de objeto se esta
manipuleando, se quiere tener una copia del mismo.
• Ejemplo: En un sistema gráfico se quiere copiar la figura
elegida por el usuario en la IU.
• Solución: Se crea una jerarquía que produce objetos
“cloneando” prototipos de acuerdo al tipo de objeto que se
quiera clonear.

33. Diseño de software
Dr. Amos Sorgen
33
Agosto 2011
Proxy
• Problema: Se quiere acceder a un objeto pero sin crearlo localmente
porque su creación local consume muchos recursos.
• Ejemplo: Se quiere acceder sólo al nombre del cliente, que reside en el
objeto tipo “cliente” en un server remoto. Seria muy costoso recrear
todo el objeto.
• Solución: Se crea una jerarquía que permita crear un objeto “liviano”
conectado al objeto “pesado”
• Generalización: “Proxy – New Function”

34. Diseño de software
Dr. Amos Sorgen
34
Agosto 2011
Chain of Responsibility
• Problema: Se quiere que las peticiones emitidas al sistema sean
atendidas por distintos objetos receptores en función del estado del
sistema (dinámicamente).
• Ejemplo: No se sabe qué impresoras está libre y se quiere que el
pedido de impresión llegue la que esta libre y lo realice.
• Solución: establecer una cadena de objetos receptores a través de los
cuales se pasa una petición formulada por un objeto emisor.
Cualquiera de los objetos receptores puede responder a la petición en
función de un criterio establecido.

35. Diseño de software
Dr. Amos Sorgen
35
Agosto 2011
Command
• Problema: Se quiere tratar a una función/
pedido/ comando como si fuera un objeto
para poder
– registrarlos,
– gestionar colas,
– restaurar el estado del sistema (si es necesario)
– tratarlos con una interfaz generalizada.
• Ejemplo: Queremos notificar distintos
sucesos en el sistema en un orden que no
sea la orden en que acontecieron.
• Solución: Los objetos en vez de invocar a
otros, crean objetos de tipo “commando” que
son ejecutados asincrónicamente a su
producción.

36. Diseño de software
Dr. Amos Sorgen
36
Agosto 2011
Command
• A a, Queue q ;
• ….
• /* a.do1;
• /* A_command hereda de Command
• A_command c = do_command(a, “do1) ;
• Q.add(c) ;
• -----------------
• Queue::serve_next {
• ….
• Command c = next();
• c.execute();
• }

37. Diseño de software
Dr. Amos Sorgen
37
Agosto 2011
Command - Solución

38. Diseño de software
Dr. Amos Sorgen
38
Agosto 2011
Iterator
• Problema: Se quiere tratar a toda colección
de objetos en forma estándar
irrespectivamente de la estructura de la
colección
• Ejemplo: Queremos siempre tener la misma
forma de tratar una colección:
– Primero(),
– Siguiente(),
– HayMas()
– ElementoActual()
• Solucion: Crear para toda clase de tipo
contenedor, el “Iterator” que se ocupa de
implementar las funciones estándar

39. Diseño de software
Dr. Amos Sorgen
39
Agosto 2011
Iterator - Solución
Vector vec = new Vector();
vec.add( new String( "hola“ ) );
vec.add( new String( "adios“ ) );
Iterator it = vec.iterator();
while ( it.hasNext() )
System.out.println( (String)
it.next() );

40. Diseño de software
Dr. Amos Sorgen
40
Agosto 2011
Mediator
• Problema: Se quiere encapsular las interacciones de todo un conjunto de
objetos (colegas) en un solo objeto para evitar tener conexiones de tipo
N:N (bajo acoplamiento).
• Los objetos ya no se comunican directamente entre sí, sino a través del mediador.
Esto reduce las dependencias entre los objetos que se comunican .
• Ejemplo: Una ventana con numerosos componentes gráficos (widgets) que
tienen fuertes dependencias entre si. reglas del tipo "si el campo de
edición E2 está lleno, entonces se inhabilita habilita el botón B1 y el campo
de edición E3”.
Se quiere desacoplar los widgets
• Solución: Crear un objeto mediador que todos los “colegas” conocen. Las
interacciones entre colegas se realizan a través del envío de mensajes al
mediador y de este a los colegas.

41. Diseño de software
Dr. Amos Sorgen
41
Agosto 2011
Mediator - Solución

42. Diseño de software
Dr. Amos Sorgen
42
Agosto 2011
Preguntas