Patrones de diseño de comportamiento: Visitor

Intención del patrón

• Representar una operación a ejecutarse en los elementos de una estructura de objetos. Visitor permite definir una nueva operación sin cambiar las clases de los elementos sobre los que opera.
• La técnica clásica para recuperar información.
• Hacer lo correcto en función del tipo de dos objetos.
• Duplicar el envío.

Ejemplo de problema

Muchas operaciones distintas y sin relación necesitan ser ejecutadas en una estructura heterogénea de objetos (o nodos). Se desea evitar ensuciar las clases con estas operaciones. Además, no se quiere tener que averiguar el tipo de cada nodo y convertirlo (cast) al tipo correcto antes de ejcutar la operación deseada.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Template method

Intención del patrón

• Define el esqueleto de un algoritmo en una operación, delegando algunos pasos a las clases derivadas del cliente. Template method permite a las subclases redefinir ciertos pasos de un algortimo sin cambiar la estructura del mismo.
• La clase base declara algoritmos "placeholders" y las clases derivadas implementan dichos algoritmos.

Ejemplo de problema

Dos componentes diferentes tienen similitudes significantes, pero no hay una interfaz o implementación común que pueda ser reutilizada. Si un cambio común a ambos componentes resulta necesario, se debe duplicar el esfuerzo en realizar ese cambio.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Strategy

Intención del patrón

• Definir una familia de algoritmos, encapsular cada uno y hacerlos intercambiables. Strategy le permite al algoritmo variar independientemente del cliente que lo usa.
• Captura la abstracción en una interfaz y encapsula la los detalles de la implementación en clases derivadas.

Ejemplo de problema

Una de las estrategias dominantes del diseño orientado a objeto es el principio Open-close.
La figura muestra cómo se logra habitualmente encapsular los detalles de la interfaz en una clase base y enterrar los detalles de la implementación en las clases derivadas. Los clientes pueden entonces acoplarse a una interfaz y no tener que experimentar los trastornos asociados con el cambio. No hay impacto cuando el número de clases derivadas cambia y tampoco lo hay cuando la implementación de una clase derivada cambia.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: State

Intención del patrón

• Permitir a un objeto cambiar su comportamiento cuando cambia su estado interno. El objeto parecerá cambiar su clase.
• Un estado orientado a objetos.
• Un Wrapper + el objeto envuelto por el Wrapper + colaboración.

Ejemplo de problema

El comportamiento de un objeto monolítico y debe cambiar su comportamiento en tiempo de ejecución según su estado. O bien, una aplicación que se caracteriza por tener extensos y numerosos sentencias case que manejan el control de flujo basado en el estado de la aplicación.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Observer

Intención del patrón

• Define una dependencia uno a muchos entre objetos, para que, cuando un objeto cambie su estado, todos sus dependencias sean notificadas y actualizadas automáticamente.
• Encapsula el componente central (o motor o núcleo) en un Subject abstracto y los componentes variables (o interfaz de usuario u opcional) en una jerarquía de Observer.
• Es la parte "View" en Model-View-Controller.

Ejemplo de problema

Un diseño molítico de gran tamaño no se ajusta bien a una nueva representación gráfica o se imponen requerimientos de seguimiento.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Null object

Intención del patrón

Encapsular la ausencia de un objeto mediante la provisión de una alternativa sustituible que ofresca un valor por defecto con comportamiento "No hacer nada". En resumen, un diseño en donde "nada resultará de nada".
Usar el patrón Null object cuando:

• Un objeto requiera de un colaborador. El patrón Null object no introduce esta colaboración; hace que se use una colaboración que ya existía.
• Alguna de las intancias del colaborador no haga nada.
• Se desee abstraer el manejo del "null" fuera del cliente.

Problema de ejemplo

Dado que una referencia a un objeto puede opcionalmente ser nula y que el resultado de la verificación de ser null es no hacer nada o usar algún valor por defecto ¿Cómo puede la ausencia de un objeto (la presencia de una referencia nula) ser tratada de manera transparente?

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Memento

Intención del patrón

Sin violar el encapsulamiento, captura y externaliza el estado interno de un objeto para que el objeto pueda ser devuelto a dicho estado posteriormente.
Una cookie mágica que encapsula un "punto de control".
Proporciona la capacidad de deshacer el estado completo de un objeto.

Ejemplo de problema

Se necesita restaurar un objeto a su estado previo (por ejemplo: operaciones del tipo "deshacer" o "rollback").

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Mediator

Intención del patrón

• Definir un objeto que encapsule como interactúan un conjunto de objetos. Este patrón promueve la pérdida de acoplamiento haciendo que dicho conjunto de objetos no estén referenciados entre ellos explicitamente. Esto permite variar su interacción de manera independiente.
• Diseñar un intermediario que permita desacoplar las parejas.

Ejemplo de problema

Se desea diseñar componentes reusables, pero las dependencias entre las posibles piezas reusables demuestran el fenómeno "código spaghetti".

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Iterator

Intención del patrón

• Proporciona una manera de acceder a los elementos de un objeto contenedor (colección) de manera secuencial sin exponer su representación subyacente.
• La librería estándar de C++ y Java tienen abstracciones que permiten desacoplar las colecciones de los algoritmos.
• Promueve al "estado completo del objeto" del recorrido de una colección.
• Recorrido polimórfico.

Ejemplo de problema

Necesidad de abstraer el recorrido de muy diferentes estructuras de datos para que los algoritmos puedan ser capaces de interactuar con cada una de forma transparente.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Interpreter

Intención del patrón

• Dado un lenguaje, define una representación para su gramática junto con un intérprete que usa la representación para interpretar sentencias en el lenguaje.
• Asignar un dominio al lenguaje, el lenguaje a una gramática y la gramática a un diseño orientado a objeto jerárquico.

Ejemplo de problema

Una clase de problemas que ocurre repetidamente en un dominio bien definido y bien entendido. Si el dominio fue caracterizado con un lenguaje, entonces los problemas podrían ser fácilmente resueltos con un motor de "interpretación".

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Command

Intensión del patrón

• Encapsular una solicitud como un objeto, lo que permite parametrizar clientes con diferentes solicitudes, cola o registro de solicitudes, y soportar operaciones que se pueden deshacer.
• Promover la "invocación de un método en un objeto" a ser un objeto "completo".
• Un callback orientado a objeto.

Ejemplo de problema

Se necesita emitir peticiones a los objetos sin saber nada de la operación que se solicita o el receptor de la solicitud.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Chain of Responsability

Intención del patrón

• Evitar el acoplamiento entre el emisor de una solicitud y quien la recibe dando a más de un objeto la posibilidad de atender la solicitud. Encadenamiento de objetos que reciben y pasan las solicitudes a lo largo de la cadena hasta un objeto que la maneja.
• Lanzar y liberar solicitudes con una canalización de procesamiento individual que contiene muchos posibles "manejadores".
• Una lista enlazada orientada a objeto con recursividad transversal.

Ejemplo de problema

Existe un potencialmente variable número de "manejadores", "elementos de procesamiento" o "nodos" y una gran cantidad de peticiones que deben ser manejadas. La necesidad de procesar eficientemente las solicitudes sin relacionar manera dura los manejadores y las precedencias; o mapeos entre la solicitud y el manejador.

Seguir leyendo el post »

Por Juan Barrionuevo