Patrones Comportamiento_Template Method

Patrón Template Method

Define el esqueleto de un algoritmo, dejando algunos pasos a las subclases. Template Method permite a las subclases redefinir ciertos pasos de un algoritmo sin cambiar la estructura del algoritmo.

Estructura

Participantes

AbstractClass: Una clase en este papel tienen un método concreto que contiene la lógica de alto nivel (el esqueleto del algoritmo) de la clase. Este es el método plantilla indicado en el diagrama. Este método llama a otros métodos, definidos en la clase AbstractClass como métodos abstractos, que invocan a la lógica de bajo nivel que varia para cada subclase de la clase AbstractClass.
ConcreteClass: Una clase en este papel es una subclase concreta de una clase AbstractClass. La clase AbstractClass sobrescribe los métodos abstractos definidos en su superclase y proporciona la lógica necesaria (los pasos del algoritmo) para completar la lógica del método plantilla.

Patrones relacionados

Strategy El patrón Strategy modifica la lógica de los objetos individuales. El patrón
Template Method modifica la lógica de una clase entera.

Patrones Comportamiento_State

Patrón State

Permite a un objeto cambiar su comportamiento cuando cambia su estado interno. El objeto parecerá pertenecer a otra clase.

Aplicabilidad

• El comportamiento de un objeto es determinado por un estado interno que cambia en respuesta a los eventos. Debe cambiar su comportamiento en tiempo de ejecución cuando cambie su estado.
• La organización de la lógica que maneja un estado de un objeto debería ser capaz de cambiar a muchos estados sin llegar a ser una gran cantidad de código inmanejable.
• Las operaciones tienen sentencias condicionales largas que dependen del estado del objeto. Este estado es representado por una constante enumerada. A menudo, varias operaciones contendrán esta misma estructura condicional. Este patrón sitúa cada rama de la sentencia condicional en una clase separada. Esto permite tratar el estado de un objeto como un objeto que puede variar de forma independiente a otros objetos.
  

Estructura
Participantes

Context: es una clase cuyas instancias exponen el comportamiento de los estados. Define la interfaz para los clientes. Las instancias de la clase Context determinan su estado actual manteniendo una referencia a una instancia de una subclase concreta de la clase State. La subclase de la clase State determina el estado.
State: es la superclase de todas las clases utilizadas para representar el estado de los objetos contexto. Define una interfaz para encapsular el comportamiento asociado con un estado particular del contexto.
StateConcretoA, StateConcretoB: Estas clases son subclases concretas de la clase State. Cada subclase implementa un comportamiento asociado con un estado del contexto.

Consecuencias

• Localiza el comportamiento dependiente del estado.
• Hace explícitas las transiciones entre estados.
• Los objetos Estado pueden compartirse.
  

Patrones relacionados

Flyweight: Se puede utilizar el patrón Flyweight para compartir objetos estado, para soportar un gran número de objetos de forma eficiente. Este patrón explica cuando y como se puede compartir un estado.
Mediator: podemos utilizar el patrón State con el patrón Mediator cuando implementamos las interfaces de usuario.
Singleton: Se pueden implementar estados utilizando el patrón Singleton.

Patrones Comportamiento_Observer

Patrón Observer

Define una dependencia 1:M entre objetos para que cuando uno cambie su estado, a todos sus dependientes les sea notificado el cambio y se actualicen automáticamente.

Motivación

Mantener la consistencia entre objetos relacionados, sin aumentar el acoplamiento entre clases.
Ejemplo: separación de la capa de presentación en una interfaz de usuario de los datos de aplicación subyacentes

Estructura
Participantes

Subject: Conoce a sus observadores, que pueden ser un número arbitrario. Proporciona una interfaz para añadir y quitar objetos observadores.
Observer: Define la interfaz de los objetos a los que se debe notificar cambios en un sujeto.
ConcreteSubject: Almacena el estado de interés para sus observadores. Envía notificaciones a sus observadores cuando su estado cambia.
ConcreteObserver: mantiene una referencia a un ConcreteSubject, almacena el estado del sujeto que le resulta de interés, implementa Observe para mantener su estado consistente con el sujeto.

Consecuencias

• Permite modificar sujetos y observadores de manera independiente.
• Reutilizar un sujeto sin reutilizar sus observadores, y viceversa.
• Añadir observadores sin tener que cambiar el sujeto ni los demás observadores.
• Acoplamiento abstracto entre el sujeto y el observador. El sujeto no sabe la clase concreta de sus observadores (acoplamiento mínimo).
• Soporte para broadcast. El sujeto envía la notificación a todos los observadores suscritos. Se pueden añadir/quitar observadores.
• Actualizaciones inesperadas. Una operación en el sujeto puede desencadenar una cascada de cambios en sus observadores. El protocolo no ofrece detalles sobre lo que ha cambiado.
  

Patrones relacionados

Adapter: El patrón Adapter puede ser utilizado para permitir a los objetos que no implementen el interface requerido participar en el patrón Observer para recibir notificaciones.
Delegation: El patrón Observer utiliza el patrón Delegation.
Mediator: El patrón Mediator es utilizado algunas veces para coordinar cambios de estado inicializados por múltiples objetos a un objeto Observable.

Patrones Comportamiento_Mediator

Patrón Mediator

Define un objeto que encapsula como interactúan un conjunto de objetos. Las comunicaciones entre objetos se realizan a través del Mediator.

Motivación

Cuando muchos objetos interactúan con otros objetos, se puede formar una estructura muy compleja, con objetos con muchas conexiones con otros objetos. En un caso extremo cada objeto puede conocer a todos los demás objetos.

Para evitar esto el patrón Mediator encapsula el comportamiento de todo un conjunto de objetos en un solo objeto.

Los objetos envían y reciben peticiones a través del mediador, este patrón implementa el comportamiento cooperativo encaminando esas peticiones a los objetos apropiados.

Estructura
Participantes

Mediador: define una interfaz para comunicarse con los otros objetos.
Mediador concreto: Implementa el comportamiento cooperativo entre los Objetos. Conoce a los Objetos.
Objetos: Cada objeto conoce su mediador, y usa a este para comunicarse con otros objetos.

Consecuencias

• Reduce la herencia.
• Desacopla a los “Colegas”.
• Simplifica los protocolos de los objetos.
• Abstrae cómo cooperan los objetos.
• Centraliza el control
  

Patrones Comportamiento_Iterator

Patrón Iterator

Proporciona una forma de acceder a los elementos de un objeto compuesto secuencialmente sin conocer su diseño.

Estructura

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.

Consecuencias

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

Patrones Comportamiento_Command

Patrón Command

El objetivo de este patrón es encapsular una petición en un objeto para tener un control más fino sobre la petición. Se le conoce también como: Action, Transaction, Orden.
Motivación

La necesidad de un paquete de herramienta de interfaz de usuarios con botones, menús sin saber que van a hacer en la aplicación Solución: encapsula la petición en un objeto como una orden – la clave es una clase abstracta Orden que tenga una interfaz para ejecutar operaciones.

Estructura

Participantes

Command: declara una interfaz para ejecutar una operación.
ConcreteCommand: define un enlace entre un objeto “Receiver” y una acción. Implementa “Execute” invocando la(s) correspondiente(s) operación(es) del “Receiver”.
Client: Crea un objeto “ConcreteCommand” y establece su receptor.
Receiver: sabe como llevar a cabo las operaciones asociadas a una petición. Cualquier clase puede hacer actuar como “Receiver”.
Invoker: le pide a la orden que ejecute la petición.
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.
  

Patrones relacionados

Factory Method: Ofrece una forma alternativa de llamar a los órdenes además del uso del command manager.
Intérprete: Se puede implementar un pequeño Intérprete mediante clases Command.
Template Method: Sirve para implementar la lógica de “Deshacer” de forma automática.
Composite y Prototype: Permite realizar agrupaciones de órdenes de forma similar a una macro. Hay quien lo utiliza para implementar la copia de la orden al histórico de órdenes.