Patrones de Diseo

1
Patrones de Diseño

• Daniel Mazzini
• dmazzini_at_ubicasolutions.com
• Ubica Solutions

2
Conocimientos previos

• Conocimientos de POO.
• UML (básico)
• C

3
Agenda

• Propósito de los patrones
• Fundamentos de diseño.

• Creación.
• Factory Method
• Singleton
• Abstract Factory

• Estructurales
• Adapter
• Facade
• Composite

• Comportamiento
• Command
• State
• Observer

4
Propósito de los patrones

• Qué es un patrón de diseño?
• Por qué usarlos?
• Categorización
• Problema - Patrón

5
Qué es un patrón de diseño?

• Ante un problema reiterado ofrece una solución
  contrastada que lo resuelve.
• Describe el problema en forma sencilla.
• Describe el contexto en que ocurre.
• Describe los pasos a seguir.
• Describe los puntos fuertes y débiles de la
  solución.
• Describe otros patrones asociados.

6
Por qué usarlos?

• Mejora en la comunicación y documentación
• Hay que hacer un Factory Method
• Facilita la documentación interna del proyecto.
• Mejora la ingeniería de software.
• Eleva el nivel del grupo de desarrollo.
• Previene reinventar la rueda en diseño
• Son soluciones ya probadas.
• Mejora la calidad y estructura
• Cuan grande debe ser una clase?

7
Categorización

• Fundamentales
• Se usan en otros patrones mas grandes
• Creación
• Aislar el proceso de creación de un objeto.
• Estructura
• Desacopla el sistema.
• Comportamiento
• Describe situaciones de control de flujo.

8
Problema - Patrón

• Crear un objeto sin especificar la clase a la que
  pertenece
• Abstract Factory
• Factory Method
• Prototype
• Dependencia para tareas especificas
• Command
• Cadena de Responsabilidad

9
Problema Patrón (cont)

• Dependencia hacia el hardware o software
• Abstract Factory
• Bridge
• Dependencia hacia los algoritmos
• Strategy
• Template Method
• Builder

10
Problema Patrón (cont)

• Alto acoplamiento
• Façade
• Mediator
• Observer
• Imposibilidad de cambiar la clases
  convenientemente
• Adapter
• Decorator
• Visitor

11
Fundamentos de diseño

• Programar para las interfaz, no para la herencia.
• Favorecer la composición antes que la herencia.
• Delegación.
• Doble Herencia.

12
Herencia o interfaz

• La herencia de clase define la implementación de
  una clase a partir de otra (excepto métodos
  abstractos)
• La herencia de interfaz define como se llamara el
  método o propiedad, pudiendo escribir distinto
  código en cada clase.

13
Programar para las interfaz

• Reutilizar la implementación de la clase base es
  la mitad de la historia.
• Ventajas
• Reducción de dependencias.
• El cliente desconoce la implementación.
• La vinculación se realiza en tiempo de ejecución.
• Da consistencia (contrato).
• Desventaja
• Indireccionamiento.

14
Favorecer la composición

• Ventajas de la herencia
• Implementación ya realizada.
• Útil en situaciones es un
• Desventajas de usar herencia
• Construir un monstruo.
• No se puede cambiar la implementación heredada en
  tiempo de ejecución.
• Quebrar la encapsulación.
• Visibilidad.

15
Favorecer la composición (cont)

• Ventajas de la composición
• Crear una nueva clase ensamblando con mas de una
  clase.
• Puede cambiar la clase con la cual ensamblo en
  tiempo de ejecución.
• Centrar cada clase en una tarea.
• Desventaja de la composición
• Requiere escribir un poco mas de código.
• Indireccionamiento.

16
Delegación

• Una forma de componer.
• Se delega un conjunto de operaciones de un objeto
  en otro objeto.
• La herencia que use en VB6.

return Delegado.operacion()
17
Anti-Ejemplo
Nuevo requerimiento No todos las ventanas son
cuadradas
18
Ejemplo de Delegado

• Quito la herencia en ventana

• Creo una interfaz para comunicar el delegador con
  el delegado

• Creo un método llamado Area en Ventana (solo para
  mantener compatibilidad)

• Llamo al método de la interfaz que me da el área

19
DEMO
Delegado
20
Delegado en .Net
21
Doble Herencia

• Problema
• Mantener las clases que implementan como internas
  del proyecto (internal o Friend), pero la
  interfaz pública.
• Organizar clases que tienen un comportamiento
  parecido para que sea consistente.

22
Doble Herencia (cont)

• Clase base es abstracta.
• La clase base puede heredar de mas de una
  interfaz.
• Una vez que están escritos los métodos, verifico
  si hay duplicación en las clases hijas.

23
Doble Herencia en .NET
24
Patrones de creación

• Propósito
• Crear un objeto es una toma de decisión.
• Separar los procesos de creación de objeto y de
  uso de un objeto.
• Cuales veremos?
• Factory Method
• Singleton
• Abstract Factory

25
Factory Method

• Problema
• La instancia del objeto a crear depende de
  condiciones externas a la clase cliente.
• Puede cambiar independientemente de cambiar la
  clase cliente.
• Ya he creado la estructura con Doble Herencia,
  pero ahora necesito poder crear una instancia de
  cualquier clase concreta.

26
Factory Method
27
DEMO
Factory Method
28
F.M. con Constructor Estático

• Método estático en clase abstracta que retorno
  instancias.
• Constructores privados o protegidos.

29
DEMO
Static Factory
30
Singleton

• Problema
• No se puede tener mas de una instancia de una
  clase.
• Se necesita controlar el acceso a una clase.

31
Singleton

• Cambio el constructor a privado.
• Hago que la clase no pueda ser heredada.
• Agrego una variable estática del mismo tipo de la
  clase donde esta contenida. (instancia)
• Agrego un método estático que retorne la variable
  estática. (GetInstance)
• No creo el objeto hasta que sea necesario (Lazy
  Creation)
• Agrego el código necesario para no crear dos
  instancias en distintos thread.

32
DEMO
Singleton
33
Abstract Factory

• Problema
• Necesito crear una familia de objetos.
• Trabajo con mas de una familia.
• No puedo combinar ítems de las familias de
  objetos.
• El resto del sistema debe trabaja sin distinguir
  entre familias de objetos.

34
Abstract Factory
35
Ruedas CrearRueda() return new Rueda26()
Ruedas CrearRueda() return new
RuedaMoto()
Ruedas CrearRueda() return new RuedaF1()
36
DEMO
Abstract Factory
37
Patrones de estructura

• Propósito
• Desacoplar el sistema.
• Obtener una estructura flexible.
• Organizar.
• Cuales veremos?
• Adapter
• Facade
• Composite

38
Facade

• Problemas
• El cliente hace muchos viajes al servidor.
• Separe por capas, pero tengo muchas clases
  públicas en el servidor para que puedan ser
  creadas desde el cliente.
• Necesito estructurar las llamadas desde el
  cliente.

39
Facade
Form Cliente
Cliente
Form Pedidos
Form Ctas Corrientes
Presentación
Lógica
40
Facade
41
Facade

• Caso de Uso Facade
• Un caso de uso es lo interacción de un actor con
  el sistema. La métodos de la fachada encapsulan
  los pasos necesarios para llevar a cabo lo que el
  cliente desea hacer.

42
DEMO
Facade
43
Adapter

• Problemas
• Necesitamos llamar a un método a través de una
  interfaz para no tener dependencia en el cliente.
• La librería a la que hay que llamar no es nuestra
  y no implementa esa interfaz.
• No contamos con el código fuente de la librería.

44
Adapter
Cliente
IOperacion
Operacion()
45
DEMO
Adapter
46
Composite

• Problema
• Estructuras de árbol o estructuras 1-N.
• Tiene un objeto complejo que hay que descomponer
  en partes.
• Nodos especiales que pueden contener otros nodos.

47
Composite
Espec Rojos new ColorEsp(Color.Red) ArrayList
prodRojos alm.Seleccionar(Rojos)
Espec RojoPeq new CompuestoAndEsp( new
ColorEsp(Color.Red), new TamañoEsp(Tamaño.Pequeño
)) ArrayList prodRojos alm.Seleccionar(RojoPeq)
Espec Peq new TamañoEsp(Tamaño.Pequeño) ArrayLi
st prodPeq alm.Seleccionar(Peq)
Especificación
EstaOK(Producto)bool
return (_espec1.EstaOK(Producto)
_espec2.EstaOK(Producto))
48
Composite
Espec ar new Espec new
ColorEsp(Color.Red), new
TamañoEsp(Tamaño.Pequeño) Espec ExpresionOr
new CompOrEsp(ar) ArrayList prodRojos
alm.Seleccionar(ExpresionOr)
Lista
ColorEsp
TamañoEsp
49
DEMO
Composite
50
Composite Dinámico
Empleado
Agregar(Empleado) Quitar(Empleado) ObtenerSueld
os()double
NodosHojas
NodosPadre
Agregar(Empleado) Quitar(Empleado) ObtenerSueld
os()double
Agregar(Empleado) Quitar(Empleado) ObtenerSueld
os()double
Empleados
51
DEMO
Composite Dinámico
52
Patrones de Comportamiento

• Propósito
• Asignación de responsabilidad Distribuir el
  comportamiento.
• Comunicación entre instancias.
• Se usa mas la composición que la herencia.
• Cuales veremos?
• Command
• Strategy
• State

53
Command

• Problema
• Operaciones repetidas (por ejemplo, en el menú y
  en el toolbar).
• Necesita controlar la secuencia de las
  operaciones.
• Necesito hacer un log de las operaciones que
  ejecuta el cliente.

54
Command
55
Command

• Tambien puedo
• Crear un método Deshacer en la Interfaz.
• Puedo crear una pila de los últimos comandos que
  se ejecutaran.
• Puedo sacar de la pila de comandos ejecutados y
  llamar al método Deshacer.
• Juntándolo con el patrón Composite puedo generar
  un comando Macro.

56
Command
Command Manager
Undo(int Cantidad) Redo(int Cantidad) CrearComa
ndo(estado)
lista
57
DEMO
Command
58
State

• Problema
• Mantener el estado de un objeto.
• La organización de la lógica que maneja el estado
  (maquina de estado) se torna incontrolable.
• Acoplamiento entre la funcionalidad propia de la
  clase y la funcionalidad para manejar el estado
  de un objeto.

59
State
60
Observer

• Problema
• Mantener distintos objetos relacionados,
  generalmente son relaciones 1 N.
• Mantener las dependencias entre objetos, sin
  necesidad de conocer al otro objeto.
• Tipos de objetos
• Publicador Aquel que tiene que notificar de un
  cambio.
• Suscriptores Aquellos interesados en recibir la
  notificación.

61
Observer
Publicador
Agregar(Observador) Quitar(Observador) Notifica
r()
foreach Observador item in al Item.Actualizar()

62
Otras consideraciones

• Puedo enviar la información necesaria a los
  suscriptores al notificar o que pida lo que
  necesita (dependencia hacia el publicador)
• Ante casos de muchos publicadores, puedo hacer un
  Gestor de Cambios que haga la función de
  mediador.
• Al notificar se puede usar delegados y pasar
  clases que hereden de EventArgs al Suscriptor.

63
DEMO
Observer y State
64
Conclusiones

• Empiece por un patron, estudie los problemas que
  resuelve y pase cuando lo haya probado.
• Si la espada ya esta sobre su cabeza, lea los
  problemas que resuelven todos los patrones.
• No deje de leer
• Patrones de Diseño, E. Gamma y otros (GoF).
• Patterns of Enterprise Application Architecture,
  Martin Fowler