Author: Gloria Riascos Delgado - Diana Rivadeneira

PATRON STRATEGY

Este patrón provee la implementación de diferentes estrategias o comportamientos concretos en clases hijas a través de una clase común.

Su propósito es definir una familia de algoritmos, encapsular cada uno de ellos y hacerlos intercambiables. Permite la variación de un algoritmo, independientemente de los clientes que lo usen.

Figura : Patrón Strategy

Fuente: http://joaquin.medina.name/web2008/documentos/informatica/documentacion/logica/patrones/patronStrategy/PatronEstrategia01.jpg

Aplicabilidad

• Muchas clases relacionadas difieren solo en su comportamiento. Las estrategias permiten configurar una clase con un determinado comportamiento entre muchos posibles.

• Se necesitan distintas variantes de un algoritmo.

• Un algoritmo usa datos que los clientes no deberían conocer. Se usa para evitar exponer estructuras de datos complejas y dependientes del algoritmo.

• Una clase define muchos comportamientos y estos se representan como múltiples sentencias condicionales en sus operaciones. En vez de tener muchos condicionales, podemos mover las ramas de estos a sus propias clases estrategia.

Componentes de este patrón:

• Interfaz Strategy: es la interfaz que define el nombre del método o métodos que conformarán la estrategia.

• Clases Strategy concretas: todas aquellas clases que implementen la interfaz Strategy dando forma al algoritmo.

• Contexto: elemento donde se desarrollará la estrategia.

Consecuencias

• Familias de algoritmos relacionados: Las jerarquías de clases Estrategia definen una familia de algoritmos o comportamientos.

• Una alternativa a la herencia: La herencia ofrece otra forma de permitir una variedad de algoritmos o comportamientos. Se puede heredar directamente de una clase contexto para proporcionar diferentes comportamientos. Pero esto liga el comportamiento al Contexto, mezclando la implementación del algoritmo con la del Contexto, lo que hace que éste sea más difícil de comprender, mantener y extender. Y no se puede modificar el algoritmo dinámicamente. Acabaremos teniendo muchas clases relacionadas cuya única diferencia es el algoritmo o comportamiento que utilizan. Encapsular el algoritmo en clases Estrategia separadas nos permite variar el algoritmo independientemente de su contexto, haciéndolo más fácil de cambiar, comprender y extender.

• Las estrategias eliminan las sentencias condicionales: El patrón estrategia ofrece una alternativa a las sentencias condicionales para seleccionar el comportamiento deseado. Cuando se juntan muchos comportamientos en una clase es difícil no usar sentencias condicionales para seleccionar el comportamiento correcto. Encapsular el comportamiento en clases estrategias separadas elimina estas sentencias condicionales, delegando la tarea en el objeto estrategia.

• Los clientes deben conocer las diferentes estrategias: el patrón tiene el inconveniente potencial de que un cliente debe comprender como difieren las Estrategias antes de seleccionar la adecuada. Los clientes pueden estar expuestos a cuestiones de i implementación. Por lo tanto, el patrón estrategia debería usarse solo cuando la variación del comportamiento sea relevante a los clientes.

• Costes de comunicación entre Estrategia y Contexto: La interfaz de Estrategia es compartida por todas las clases Estrategia Concreta, ya sea el algoritmo que implementa trivial o completamente. Por lo tanto, es probable que algunos objetos Estrategia Completa no usen toda la información que reciben a través de dicha interfaz; las estrategias concretas simples pueden incluso no utilizar nada de dicha información. Esto significa que habrá veces en las que el contexto crea e inicializa parámetros que nunca e utilizan. Si esto puede ser un problema, necesitaremos un acoplamiento más fuerte entre Estrategia y Contexto.

• Mayor número de objetos: Las estrategias aumentan el número de objetos de una aplicación. A veces se puede reducir este coste implementando estrategias como objetos sin estado que puedes ser compartida por el contexto. El contexto mantiene cualquier estado residual, pasándolo en cada petición de al objeto estrategia. Las estrategias compartidas no deberían mantener el estado entre invocaciones.

(Serrano, 2013)