I. PATRÓN DE DISEÑO: STRATEGY

A continuación se encuentra la plantilla del patrón objeto de estudio:

1. Nombre del patrón: Strategy.

2. Clasificación del patrón: De comportamiento.

3. Intención: Definir una familia de algoritmos, encapsular cada uno de ellos y hacerlos intercambiables. Strategy permite al algoritmo variar independientemente del cliente que use este.
La idea es crear sistemas usando la composición dando mayor flexibilidad. No solamente permite encapsular una familia de algoritmos dentro de su propio conjunto de clases, sino que también permite cambiar el comportamiento en tiempo de ejecución

4. Aplicabilidad:

Este patrón se usa cuando:

•Se necesita diferentes variantes de un algoritmo. Strategy puede ser usado cuando estas variantes son implementadas como una jerarquía de clases de algoritmos.
•Cuando muchas clases relacionadas difieren solamente en su comportamiento. Strategy suministra un camino para configurar una clase con uno de muchos comportamientos.
•Cuando se desee evitar exponer la complejidad, de la estructura de datos de un algoritmo especifico.
•Cuando una clase define muchos comportamientos y estos aparecen con instrucciones condicionales en sus operaciones. En vez de muchas condicionales, mueva las bifurcaciones de las condicionales dentro de su propia clase estrategia.

5. Estructura:


6. Participantes:

•Strategy: Declara una interfaz común para dar soporte a todos los algoritmos Context, utiliza esta interfaz para llamar al algoritmo definido por un ConcreteStrategy.
•Concretestrategy: Implementa el algoritmo usando la interfaz Strategy.
•Context: se configura con un objeto ConcreteStrategy, sobre el que mantiene una referencia, puede definir una interfaz que permita a Strategy acceder a sus datos.

7. Colaboraciones:

•La estrategia y el contexto interactúan para implementar el algoritmo escogido. Un contexto puede pasar todos los datos requeridos por el algoritmo a la estrategia cuando el algoritmo es llamado.
•El contexto remite un requerimiento desde los clientes a la estrategia. Los clientes usualmente crean y pasan un objeto ConcreteStrategy al contexto. Después de eso los clientes interactúan con el contexto exclusivamente.


8. Consecuencias:

•Al favorecer la composición sobre la herencia facilita soportar variedad de comportamientos y su implementación.
•Reuso.
•Incrementa el número de objetos.

I. PATRÓN DE DISEÑO: OBSERVER

A continuación se encuentra la plantilla del patrón objeto de estudio:

1. Nombre del patrón: Observer.

2. Clasificación del patrón: De comportamiento.

3. Intención: Define una o muchas dependencias entre objetos de tal forma que cuando un objeto cambia de estado todos sus dependientes son notificados automáticamente y actualizados.
Los observadores son dependientes de un sujeto.Y cuando reciben notificación de que el estado el sujeto cambia, se pueden actualizar con nuevos valores.

4. Estructura:




5. Participantes

Subject: Conoce sus observadores y proporciona una interfaz para gestionarlos.

ConcreteSubject: Almacena el estado de interés y envía una notificación a sus observadores cuando su estado cambia.

Observer: Define una interfaz para los objetos a los que debe notificarse el cambio de estado en ConcreteSubject.

ConcreteObserver: Mantiene una referencia a un objeto ConcreteSubject, mantiene información consistenete relacionada con el estado implementando el método Update().

6. Consideraciones:

•El sujeto contiene un estado y lo controla. Los observadores confían en el sujeto para que éstos le digan, cuando cambia su estado.
•Dado que el sujeto es el propietario exclusivo de los datos (estado), los observadores son dependientes de que el sujeto los actualice cuando los datos cambian.
•Los sujetos y los observadores están bajamente acoplados (ellos pueden interactuar pero tienen muy poca información el uno del otro):
Lo único que el sujeto sabe es que el observador implementa una interfaz (update ()).
•Se pueden adicionar observadores en cualquier momento ya que la única cosa de la cual depende el sujeto es de una lista de objetos que implementan la interfaz Observer.
•No se necesita modificar el sujeto para adicionar nuevos tipos de observadores. (Solo se necesita implementar la interfaz observer y el sujeto notificará a cualquier objeto que implemente esa interfaz.
•Esforzar por diseños con bajo acoplamiento entre objetos que interactúan.
•Ya que permiten construir sistemas orientados a objetos más flexibles que puedan manejar cambios porque ellos minimizan la interdependencia entre objetos.

I. PATRÓN DE DISEÑO: TEMPLATE METHOD

A continuación se encuentra la plantilla del patrón objeto de estudio:

1. Nombre del patrón: Template Method.

2. Clasificación del patrón: De comportamiento.

3. Intención: Definir el esqueleto de un algoritmo en una operación, defiriendo algunos pasos a las subclases. Template method permite a las subclases redefinir ciertos pasos de un algoritmo, sin cambiar la estructura del algoritmo.

4. Estructura:




5. Participantes

AbstractClass: Define operaciones primitivas abstractas cuya concreción se delega a las subclases, estas primitivas se utilizan en el cuerpo de un algoritmo del esqueleto.

ConcreteClass: Implementa las operaciones primitivas abstractas anteriores.

I. PATRÓN DE DISEÑO: VISITOR

A continuación se encuentra la plantilla del patrón objeto de estudio:

1. Nombre del patrón: Visitor.

2. Clasificación del patrón: De comportamiento.

3. Intención: Representa una operación para ser ejecutada sobre los elementos de una estructura de objetos. Visitor permite definir una nueva operación sin cambiar las clases de los elementos sobre los cuales éste opera. Proporciona un marco genérico para soportar operaciones sobre un grupo de clases.

4. Estructura:



5. Participantes

Visitor: Establece las operaciones a realizar.

ConcreteVisitor: Implementa dichas operaciones.

Element: Define un método Accept() que toma un visitor como argumento.

ConcreteElement: Implementa el método Accept().

6. Consideraciones:

•Utilice el patron visitor cuando:

- Un sistema contiene un grupo de clases relacionadas.
- Tiene que realizar algunas operaciones no triviales sobre algunas o todas las clases relacionadas.
- Las operaciones deben ejecutarse de forma diferente para las distintas clases.

•Alta flexibilidad para añadir operaciones.
•Si se modifica las clases Element se debe reescribir el código del visitor. Cualquier clase adicional hace necesario definir un nuevo método en la interfaz Visitor y cada ConcreteVisitor tiene que proporcionar una implementación para ese método.

I. PATRÓN DE DISEÑO: STATE

A continuación se encuentra la plantilla del patrón objeto de estudio:

1. Nombre del patrón: State.

2. Clasificación del patrón: De comportamiento.

3. Intención: Permite a un objeto cambiar su comportamiento cuando su estado interno cambia. El objeto parecerá cambiar su clase.


4. Estructura:



5. Participantes

Context: Define la interfaz de interés a clientes.

State: Define una interfaz para encapsular el comportamiento asociado con un estado particular del contexto..

ConcreteState: Cada subclase implementa un comportamiento asociado con un estado de context.

6. Patrones Relacionados:

•Strategy

I. PATRÓN DE DISEÑO: MEDIATOR

A continuación se encuentra la plantilla del patrón objeto de estudio:

1. Nombre del patrón: Mediator.

2. Clasificación del patrón: De comportamiento.

3. Intención: Gestionar la comunicación entre distintos objetos, sin que éstos necesiten conocerse entre sí.

Objetos que inractuan para proporcionarse servicios entre si (altamente acoplados).

Mediator sugiere abstraer todos los detalles de interacción entre un grupo de objetos en una clase aparte.
Cada objeto en el grupo es responsable de ofrecer el servicio para el cual fue diseñado pero los objetos no interactúan unos con otros directamente para éste propósito.

Ejemplo:


4. Estructura:



5. Participantes

Mediator: Define una interfaz para la comunicación entre objetos Colleagues.

ConcreteMediator: Implementa un comportamiento cooperativo coordinado objetos Colleague.

Aggregate: Define una interfaz para crear un objeto iterator.

Colleague classes: Cada objeto colleague conoce su objeto Mediator, cada colleague comunica con su mediator cuando tiene que comunicar con otro colleague.

6. Consecuencias:

•Incrementa la reusabilidad de los objetos soportados por el mediador desacoplándolos del sistema en el cual se encuentran inmersos.
•Simplifica el mantenimiento del sistema centralizando la lógica de control.
•El mediador es comúnmente utilizado para coordinar componentes de la interfaz gráfica de usuario (GUI) relacionados.
•El objeto mediador en sí mismo puede empezar a ser bastante complejo.

I. PATRÓN DE DISEÑO: ITERATOR

A continuación se encuentra la plantilla del patrón objeto de estudio:

1. Nombre del patrón: Iterator.

2. Clasificación del patrón: De comportamiento.

3. Intención: Suministra una forma para acceder secuencialmente los elementos de una colección sin exponer su representación subyacente.

4. Estructura:



5. Participantes

Iterator: Define una interfaz para atravesar y acceder a los elementos.

ConcreteIterator: Implementa la interfaz del iterator, mantiene un puntero al conjunto de elementos.

Aggregate: Define una interfaz para crear un objeto iterator.

ConcreteAggregate: Implementa la interfaz de creación del iterator devolviendo un objeto de ConcreteIterator apropiado.