PATRONES DE DISEÑO. Patrones estructurales (Structural patterns)

Presentación del tema: "PATRONES DE DISEÑO. Patrones estructurales (Structural patterns)"— Transcripción de la presentación:

1 PATRONES DE DISEÑO

2 Patrones estructurales (Structural patterns)

3 Patrón Adapter Propósito. Convertir la interfaz de una clase en otra esperada por el cliente Motivación Shape EditorDibujo BoundigBox() createManipulator TextView getExtent() TextShape BoundigBox() createManipulator LineShape BoundigBox() createManipulator Patrones estructurales

4 Estructura. Class Adapter El adaptador implementa la intertaz del Target y extiende la clase adaptada Target Adapter Client request() request() Adaptee specificRequest() Patrones estructurales

5 Patrón Adapter Estructura. Object adapter. El adaptador extiende la interfaz del target y tiene un objeto del tipo del objeto adaptado (composición) Target Adapter Client Request() request() Adaptee specificRequest() Target Adapter Client Request() request() Adaptee specificRequest() Patrones estructurales

6 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) Patrones estructurales

7 Bridge (puente) Propósito. Desacoplar una abstracción de su implementación de manera que las dos puedan variar independientemente Motivación WindowImp XWindowImp devDrawText() devDrawText() PMWindowImp devDrawText() Window drawText() drawRect() IconWindow() drawBorder() DialogWindow() drawBorder() Patrones estructurales

8 Estructura Implementador ConcreteImplA operationImp() operationImp() ConcreteImplB operationImp() Abstraction operacion() RefinedAbstraction Abstraction operacion()

9 Participantes  Abstracción (Window)  RefinedAbstraction (IconWindow)  Implementor (WindowImp)  ConcreteImplementor (XwindowImp, PMWindowImp Colaboraciones.  La abstracción envía las solicitudes de los clientes a las implementaciones Patrones estructurales

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

11 Composite (composición) Organizar objetos en estructuras de árbol para representar jerarquías todo-parte. Permite a los clientes tratar de manera uniforme a objetos individuales y a agrupaciones de objetos Motivación Graphic Rectangle draw() add(graphic) remove(graphic) draw() Picture draw() add(graphic) Line draw() Patrones estructurales

12 Estructura Componente Hoja operacion() agregar(comp) eliminar(comp) operacion() Compuesto operation() agregar(comp) Cliente

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 Decorator (decorador). Wrapper Propósito. Dar responsabilidades adicionales a un objeto dinámicamente. Es una alternativa a la herencia para extender funcionalidad Motivación Patrones estructurales VisualComponent TextView draw() draw() Decorator ScrollDecorator draw() drawBorder() draw() BorderDecorator draw() drawBorder()

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 TextView operation() operation() Decorator operation() ConcreteDecoratorB operation() addedBehavior() ConcreteDecoratorA 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 Patrón Facade (fachada) Propósito. Proveer una interfaz unificada a un conjunto de interfaces que constituyen un subsistema Motivación. Un sistema administrativo Cliente Factura Artículo ManejadorFacturas (la fachada) Un compilador Escaner, Parser, BytecodeStream Compilador (la fachada) Patrones estructurales

20 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 Patrón Command Propósito. Encapsular una solucitud como un objeto de manera que se puedan parametrizar clientes con diferentes solicitudes, poner solicitudes en cola y soportar “deshacer operaciones” Motivación. Patrones de diseño MenuIte m Menu Command execute() Applicati on Clicked addMenuIte m() command.execu te()

35 Aplicabilidad. Usar el patrón command cuando se desea Parametrizar objetos con una acción a realizar Especificar, encolar y ejecutar solicitudes en diferentes momentos Soportar desacer. La operación execute puede almacenar estado para revertir efectos en el objeto command Estructura. Patrones de diseño Invoker ConcreteCommand Client execute() Command execute() ConcreteCommand 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 Patrón Iterator Propósito. Proveer un mecanismo para acceder a los elementos de un objeto “agregado” sin exponer su representación interna Motivación AbstractList Iterator first() next() isDone() currentItem() ListIterator Patrones de diseño createIterator() append() remove() List Client

39 Aplicabilidad. Usar para Acceder al contenido de un objeto agregado sin exponer su representación interna Soportar múltiples formas de recorrer el agregado Proveer una plataforma común para recorrer objetos agregados diferentes Estructura. Agregate Iterator first() next() isDone() currentItem() ConcreteIterator Patrones de diseño createIterator() ConcreteAgregat e createIterator()

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 Patrón Strategy Propósito. Definir una familia de algoritmos, encapsularlos y hacerlos intercambiables Motivación. Composition Compositor compose() ArrayCompositor Traverse() repair() TexCompositor SimpleCompositor compose() Patrones de diseño

43 Aplicabilidad. Usar Strategy cuando Muchas clases relacionadas difieren solamente en su comportamiento. Permite configurar una clase con uno de múltiples comportamientos Se necesitan diferentes variantes de un algortimo. Un algoritmo usa datos cuya estructura los clientes no deben conocer. Una clase define muchos comportamientos Patrones de diseño

44 Estructura. Context Strategy AlgorithmInterface( ) ConcreteStrategyC contextInterface( ) ConcreteStrategyB ConcreteStrategyA AlgorithmInterface() Patrones de diseño

45 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 Attach(observer ) detach(observer ) notify() Observer Update() ConcreteObserver Update() ObserverState Subject 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 HelpHandle r 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 HandleReque st() ConcreteHand ler1 HandleRequest( ) ConcreteHand ler2 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.