Tarea 5 Patrones de diseño

Template Method

Define una estructura algorítmica cuya lógica quedará a cargo de las subclases. Para ello, escribe una clase abstracta que contiene parte de la lógica necesaria para realizar su finalidad. En ella se define una estructura de herencia que sirve de plantilla ("Template" significa plantilla) de los métodos en las subclases.

Dicho de otra forma, define un esqueleto de un algoritmo, delegando algunos pasos a las subclases. Permite redefinir parte de dicho algoritmo sin cambiar su estructura.

Se debe utilizar este patrón cuando.

Se quiera factorizar el comportamiento común de varias subclases.

Se necesite implementar las partes fijas de un algoritmo una sola vez y dejar que las subclases implementen las partes variables.

Se busque controlar las ampliaciones de las subclases, convirtiendo en métodos plantillas aquéllos métodos que pueden ser redefinidos.

Este patrón se vuelve de especial utilidad cuando es necesario realizar un algoritmo que sea común para muchas clases, pero con pequeñas variaciones entre una y otras. En este caso, se deja en las subclases cambiar una parte del algoritmo.

AbstractTemplate o AbstractClass: implementa un método plantilla que 

define el esqueleto de un algoritmo y define métodos abstractos que deben implementar las subclases concretas

TemplateConcreto o ConcreteClass: implementa los métodos abstractos para realizar los pasos del algoritmo que son específicos de la subclase.

Command

Encapsula un mensaje como un objeto. Especifica una forma simple de separar la ejecución de un comando, del entorno que generó dicho comando. Permite solicitar una operación a un objeto sin conocer el contenido ni el receptor real de la misma. Si bien estas definiciones parecen un tanto ambigüas, sería oportuno volver a leerlas luego de entender el ejemplo.

Este patrón suele establecer en escenarios donde se necesite encapsular una petición dentro de un objeto, permitiendo parametrizar a los clientes con distintas peticiones, encolarlas, guardarlas en un registro de sucesos o implementar un mecanismo de deshacer/repetir.

Se debe usar cuando:

Se necesiten colas o registros de mensajes.

Se deba tener la posibilidad de deshacer las operaciones realizadas.

Se necesite uniformidad al invocar las acciones.

Se quiera facilitar la parametrización de las acciones a realizar.

Se quiera independizar el momento de petición del de ejecución.

El parámetro de una orden puede ser otra orden a ejecutar.

Se busque desarrollar sistemas utilizando órdenes de alto nivel que se construyen con operaciones sencillas (primitivas).

Se necesite sencillez al extender el sistema con nuevas acciones.

Lo que permite el patrón Command es desacoplar al objeto que invoca a una operación de aquél que tiene el conocimiento necesario para realizarla. Esto nos otorga muchísima flexibilidad: podemos hacer, por ejemplo, que una aplicación ejecute tanto un elemento de menú como un botón para hacer una determinada acción. Además, podemos cambiar dinámicamente los objetos Command. 

Command: declara una interfaz para ejecutar una operación.

CommandConcreto: define un enlace entre un objeto “Receiver” y una acción. Implementa el método execute invocando la(s) correspondiente(s) operación(es) del “Receiver”.

Cliente: crea un objeto “CommandConcreto” y establece su receptor.

Invoker: le pide a la orden que ejecute la petición.

Receiver: sabe como llevar a cabo las operaciones asociadas a una petición. Cualquier clase puede hacer actuar como receptor.

Visitor

Busca separar un algoritmo de la estructura de un objeto. La operación se implementa de forma que no se modifique el código de las clases sobre las que opera.

Si un objeto es el responsable de mantener un cierto tipo de información, entonces es lógico asignarle también la responsabilidad de realizar todas las operaciones necesarias sobre esa información. La operación se define en cada una de las clases que representan los posibles tipos sobre los que se aplica dicha operación, y por medio del polimorfismo y la vinculación dinámica se elige en tiempo de ejecución qué versión de la operación se debe ejecutar. De esta forma se evita un análisis de casos sobre el tipo del parámetro.

Este patrón debe utilizarse cuando.

Una estructura de objetos contiene muchas clases de objetos con distintas interfaces y se desea llevar a cabo operaciones sobre estos objetos que son distintas en cada clase concreta.

Se quieren llevar a cabo muchas operaciones dispares sobre objetos de una estructura de objetos sin tener que incluir dichas operaciones en las clases.

Las clases que definen la estructura de objetos no cambian, pero las operaciones que se llevan a cabo sobre ellas.

Dado que este patrón separa un algoritmo de la estructura de un objeto, es ampliamente utilizado en intérpretes, compiladores y procesadores de lenguajes, en general.

Se debe utilizar este patrón si se quiere realizar un cierto número de operaciones, que no están relacionadas entre sí, sobre instancias de un conjunto de clases, y no se quiere “contaminar” a dichas clases.

Visitor: declara una operación de visita para cada uno de los elementos concretos de la estructura de objetos. Esto es, el método visit().

VisitorConcreto : implementa cada una de las operaciones declaradas por Visitor. 

Element: define la operación que le permite aceptar la visita de un Visitor.

ConcreteElement: implementa el método accept() que se limita a invocar su correspondiente método del Visitor.

ObjectStructure: gestiona la estructura de objetos y puede ofrecer una interfaz de alto nivel para permitir a los Visitor visitar a sus elementos.