PATRONES DE DISEO

1
PATRONESDE DISEÑO
2
Patrones estructurales(Structural patterns)
3
Patrones estructurales
Shape
EditorDibujo
TextView
getExtent()
BoundigBox() createManipulator
TextShape
LineShape
BoundigBox() createManipulator
BoundigBox() createManipulator
4
Patrones estructurales

• Estructura. Class Adapter
• El adaptador implementa la intertaz del Target y
  extiende la clase adaptada

Target
Client
Adaptee
request()
specificRequest()
Adapter
request()
5
Patrones estructurales
Target
Target
Client
Client
Adaptee
Adaptee
Request()
Request()
specificRequest()
specificRequest()
Adapter
Adapter
request()
request()
6
Patrones estructurales

• Participantes
• Target (Figura)
• Client (EditorDibujo)
• Adaptado (TextView)
• Adaptador (FiguraDeTexto)
• Colaboraciones
• Los clientes invocan operaciones a un objeto del
  tipo Adapter
• A su vez el adaptador invoca operaciones en un
  objeto de la clase del adaptador (o invoca
  operaciones definidas en la superclase)

7
Patrones estructurales
WindowImp
Window
devDrawText()
drawText() drawRect()
PMWindowImp
XWindowImp
DialogWindow()
IconWindow()
devDrawText()
devDrawText()
drawBorder()
drawBorder()
8
Patrones estructurales

• Estructura

Implementador
Abstraction
Abstraction
operationImp()
operacion()
operacion()
ConcreteImplA
ConcreteImplB
RefinedAbstraction
operationImp()
operationImp()
9
Patrones estructurales
10
Patrones estructurales

• Consecuencias
• Desacoplamiento entre interfaz e implementación
• Más facilidad para extender el sistema
• Esconde los detalles de la implementación

11
Patrones estructurales
Graphic
draw() add(graphic) remove(graphic)
Line
Rectangle
Picture
draw()
draw()
draw() add(graphic)
12
Patrones estructurales

• Estructura

Componente
Cliente
operacion() agregar(comp) eliminar(comp)
Hoja
Compuesto
operacion()
operation() agregar(comp)
13
Patrones estructurales

• Participantes
• Componente (Figura)
• Hoja (Rectángulo, círculo, línea, texto)
• Compuesto (Dibujo)
• Cliente
• Colaboraciones
• Los clientes usan la interfaz Componente para
  interactuar con objetos en la jerarquía Composite
  
• Si el receptor es una hoja la solicitud es
  manejada directamente. Si es un Compuesto la
  solicitud es pasada a sus Componentes hijos

14
Patrones estructurales

• Consecuencias
• Define jerarquías de objetos primitivos y
  compuestos que son iguales para los clientes
• Hace más simple al cliente. Los clientes pueden
  manejar los objetos simples y compuestos de una
  misma forma
• Facilita el agregar nuevos tipos de componentes.
  Los nuevos objetos funcionan bien con el código
  de cliente existente

15
Patrones estructurales
VisualComponent
draw()
TextView
Decorator
draw()
draw()
16
Patrones estructurales

• Aplicabilidad
• Para agregar funcionalidad a objetos individuales
  dinámicamente sin afectar otros objetos
• Cuando la extensión por herencia es impráctica
• Participantes
• Componente
• ComponenteConcreto
• Decorador
• DecoradorConcreto

17
Patrones estructurales

• Estructura

Component
operation()
TextView
Decorator
operation()
operation()
ConcreteDecoratorB
operation() addedBehavior()
18
Patrones estructurales

• Colaboraciones
• Decorator pasa las solicitudes a su objeto
  interno. Puede realizar operaciones adicionales
  antes o después de invocar al objeto.
• Consecuencias
• Más flexibilidad que usar herencia
• Evita que las clases tengan exceso de
  características
• Un decorador y su componente no son idénticos
• Muchos objetos pequeños.

19
Patrones estructurales
20
Patrones estructurales

• Aplicabilidad. Usar Fachada cuando
• Se desea proveer una interfaz simple a un sistema
  complejo
• Hay muchas dependencias entre los clientes y las
  clases que implementan una abstracción
• Se desea organizar el sistema en capas.
• Participantes
• Fachada. Sabe cuales clases son responsables de
  una solicitud
• Clases del subsistema. Implemente la funcionalidad

21
Patrones estructurales

• Colaboraciones
• Los clientes se comunican con el subsistema
  enviando solicitudes a la fachada, la cual las
  envía a los objetos apropiados. La fachada puede
  hacer cierto trabajo adicional.
• Los clientes que usan la fachada no tienen acceso
  a los objetos del subsistema.

22
Patrones estructurales

• Consecuencias
• Aísla a los clientes de los componentes del
  subsistema, lo cual reduce el número de
  componentes que el cliente utiliza
• Promueve un acoplamiento débil entre el
  subsistema y los clientes.
• No impide que las aplicaciones utilicen las
  clases del subsistema.

23
Patrones estructurales

• Patrón Flyweight.
• Propósito. Compartir objetos cuando la cantidad
  es muy grande.
• Motivación.
• Los caracteres de un procesador de palabras
  podrían ser objetos.
• La cantidad de caracteres en un documento puede
  ser muy grando
• Cada caracter es compartido por los objetos que
  lo contetienen.

24
Patrones estructurales

• Estado intrínseco y extríniseco
• El estado intrínseco es almacenado en el objeto.
• El estado extrínseco es pasado (contexto) como
  parámetro en las operaciones.
• Aplicabilidad. Usar Flyweight cuando
• Una aplicación usa un gran número de objetos
• Los costos de almacenamiento son altos debido al
  gran número de objetos
• La mayor parte del estado del objeto puede ser
  extrínseco

25
Patrones estructurales

• Estructura

26
Patrones estructurales

• Participantes
• Flyweight
• ConcreteFlyweight
• UnsharedConcreteFlyweight
• FlyweightFactory
• Cliente

27
Patrones estructurales

• Colaboraciones
• Los clientes no crean directamente los objetos
  Flyweight, sino que deben invocar las fábricas
• El estado extrínseco es mantenido por el cliente
  y pasado cuando se invocan métodos que lo
  requieren.
• Consecuencias
• Produce ahorro de la capacidad almacenamiento
• Reduce el número total de objetos
• Reduce el tamaño del estado intrínseco por objeto.

28
Patrones estructurales

• Proxy. Provee un sustituto de un objeto
• Motivación
• Un procesador de palabras debe crear muchos
  objetos. Algunos son costosos (imágenes)
• En lugar de crear imágenes al abrir el documento,
  se crea un proxy
• Cuando se necesita la imagen el proxy la crea

29
Patrones estructurales

• Aplicabilidad
• Remote proxy. Provee un representante local de
  objetos que están en otro espacio de direcciones
  (embajador)
• Proxy virtual. Usado para crear objetos costosos
  por demanda
• Protection proxy. Provee control de acceso a
  ciertos objetos.

30
Patrones estructurales

• Estructura

31
Patrones estructurales

• Participantes
• Proxy.
• Mantiene una referencia que permite al proxy
  acceder al sujeto real
• Provee una interfaz idéntica a la del sujeto
• Controla el acceso al objeto real y puede ser
  responsible de crearlo y destruirlo
• Subject
• RealSubject

32
Patrones estructurales

• Colaboraciones
• El proxy envía solicitudes a los sujetos reales
  cuando sea apropiado.
• Consecuencias
• Un proxy remoto puede ocultar el hecho de que el
  objeto reside en otro proceso
• Un proxy virtual puede realizar optimizaciones,
  tales como crear un objeto por demanda

33
Patrones de comportamiento(Behavioral patterns)
34
Patrones de diseño
MenuItem
Command
Menu
Application
execute()
Clicked
addMenuItem()
command.execute()
35
Patrones de diseño
Invoker
Client
Command
execute()
ConcreteCommand
ConcreteCommand
execute()
execute()
36
Patrones de diseño

• Participantes
• Command
• ConcreteCommand
• Client
• Invoker
• Receiver
• Colaboraciones
• El cliente crea un comando concreto y especifica
  el recibidor
• Todos los invocadores guardan el objeto command
• El invocador emite una solicitud invocando
  execute en el comando
• El comando concreto invoca operaciones en el
  recibidor para realizar la solicitud

37
Patrones de diseño

• Consecuencias
• Comando desacopla a los objetos que invocan la
  operación del objeto que sabe como realizarla.
• Los comandos pueden ser extendidos
• Es fácil agregar nuevos comandos porque no hay
  que cambiar las clases existentes.

38
Patrones de diseño
AbstractList
Iterator
Client
createIterator() append() remove()
first() next() isDone() currentItem()
List
ListIterator
39
Patrones de diseño
Agregate
Iterator
first() next() isDone() currentItem()
createIterator()
ConcreteAgregate
createIterator()
ConcreteIterator
40
Patrones de diseño

• Participantes
• Iterator. Define una interfaz para recorrer los
  elementos
• ConcreteIterator. Implementa la interfaz
  iterator.
• Aggregate. Define una interfaz para crear un
  objeto iterador
• ConcreateAggregate. Implementa la interfaz de
  creación del iterador.
• Colaboraciones.
• Un iterador concreto lleva registro del objeto
  actual en el agregado y determina el objeto
  siguiente en el recorrido.

41
Patrones de diseño

• Consecuencias
• Soporta variaciones en el recorrido de un
  agregado
• Los iteradores simplifican la interfaz del
  agregado.
• Puede haber más de un recorrido pendiente.

42
Patrones de diseño
Compositor
Composition
compose()
Traverse() repair()
SimpleCompositor
TexCompositor
compose()
compose()
ArrayCompositor
compose()
43
Patrones de diseño
44
Patrones de diseño
Strategy
Context
AlgorithmInterface()
contextInterface()
ConcreteStrategyA
ConcreteStrategyB
AlgorithmInterface()
AlgorithmInterface()
ConcreteStrategyC
AlgorithmInterface()
45
Patrones de diseño

• Participantes
• Strategy. Declara una interfaz común a todos los
  algoritmos soportados
• ConcreteStrategy. Implementa el algoritmo que que
  usa la interfaz strategy.
• Context.
• Se configuran con un objeto ConcreteStrategy
• Mantiene una referencia a un objeto Strategy
• Puede definir una interfaz que permite acceder a
  sus datos

46
Patrones de diseño

• Colaboraciones
• La estrategia y el contexto interactúan para
  implementar el algoritmo seleccionado.
• Un contexto envía las solicitudes que le hacen
  los clientes a la estrategia.
• Consecuencias
• Es una alternativa a la herencia
• Eliminan estructuras condicionales
• Selección de implementaciones.

47
Patrones de diseño

• Patrón Observer
• Propósito. Definir una relación de dependencia
  uno a muchos entre objetos de manera que cuando
  el estado de un objeto cambia, todos sus
  dependientes son notificados y actualizados
  automáticamente.
• Motivación

48
Patrones de diseño

• Aplicabilidad. Usar en las siguientes situaciones
• Cuando una abstracción tiene dos aspectos, uno
  dependiente del otro.
• Cuando un cambio a un objeto requiere cambios en
  otros y no se sabe cuantos objetos deben ser
  cambiados.
• Cuando un objeto debe ser capaz de notificar a
  otros objetos sin saber quienes son.

49
Patrones de diseño

• Estructura

Subject
Observer
Attach(observer) detach(observer) notify()
Update()
ConcreteObserver
Update()
Subject
ObserverState
attach(observer) detach(observer) notify()
SubjectState
50
Patrones de diseño

• Participantes
• Subject
• Observer
• ConcreteSubject
• ConcreteObserver
• Colaborations
• ConcreteSubject notifica a sus observadores
  cuando ocurre un cambio
• Al ser informado del cambio el observador puede
  solicitar al sujeto información sobre dichos
  cambios

51
Patrones de diseño

• Patrón Chain of Responsibility
• Evitar acoplar al receptor de una solititud con
  el receptor.
• Motivación. Sistema de ayuda

HelpHandler
HandleHelp()
Widget
52
Patrones de diseño

• Aplicabilidad. Usar cuando
• Más de un objeto puede manejar una solicitud. No
  se sabe quién manejará la solicitud.
• Se desea emitir una solicitud a uno de varios
  objetos sin decir quién la realizará.
• Se debe especificar dinámicamente el conjunto de
  objetos que pueden manejar una solictud

53
Patrones de diseño

• Estructura

Handler
HandleRequest()
ConcreteHandler2
ConcreteHandler1
HandleRequest()
HandleRequest()
54
Patrones de diseño

• Participantes
• Handler
• ConcreteHandler
• Client
• Colaboraciones.
• Cuando un cliente emite una solicitud, ésta se
  propaga a lo largo de la cadena hasta que un
  manejador concreto asuma la responsabilidad de
  manejarlo.