# Strategy (patrón de diseño)

El patrón Estrategia (Strategy) es un patrón de diseño para el desarrollo de software. Se clasifica como patrón de comportamiento porque determina cómo se debe realizar el intercambio de mensajes entre diferentes objetos para resolver una tarea. El patrón estrategia permite mantener un conjunto de algoritmos de entre los cuales el objeto cliente puede elegir aquel que le conviene e intercambiarlo dinámicamente según sus necesidades.

## Motivación

Suponiendo un editor de textos con diferentes algoritmos para particionar un texto en líneas (justificado, alineado a la izquierda, etc.), se desea separar las clases clientes de los diferentes algoritmos de partición, por diversos motivos:
* Incluir el código de los algoritmos en los clientes hace que estos sean demasiado grandes y complicados de mantener y/o extender.
* El cliente no va a necesitar todos los algoritmos en todos los casos, de modo que no queremos que dicho cliente los almacene si no los va a usar.
* Si existiesen clientes distintos que usasen los mismos algoritmos, habría que duplicar el código, por tanto, esta situación no favorece la reutilización.
La solución que el patrón estrategia supone para este escenario pasa por encapsular los distintos algoritmos en una jerarquía y que el cliente trabaje contra un objeto intermediario contexto. El cliente puede elegir el algoritmo que prefiera de entre los disponibles, o el mismo contexto puede ser el que elija el más apropiado para cada situación.

## Aplicabilidad

Cualquier programa que ofrezca un servicio o función determinada, que pueda ser realizada de varias maneras, es candidato a utilizar el patrón estrategia. Puede haber cualquier número de estrategias y cualquiera de ellas podrá ser intercambiada por otra en cualquier momento, incluso en tiempo de ejecución. Si muchas clases relacionadas se diferencian únicamente por su comportamiento, se crea una superclase que almacene el comportamiento común y que hará de interfaz hacia las clases concretas.
Si un algoritmo utiliza información que no deberían conocer los clientes, la utilización del patrón estrategia evita la exposición de dichas estructuras. Aplicando el patrón a una clase que defina múltiples comportamientos mediante instrucciones condicionales, se evita emplear estas instrucciones, moviendo el código a clases independientes donde se almacenará cada estrategia.
Efectivamente, como se comenta anteriormente, este patrón de diseño nos sirve para intercambiar un sinnúmero de estrategias posibles.

## Participantes

Contexto (Context) : Es el elemento que usa los algoritmos, por tanto, delega en la jerarquía de estrategias. Configura una estrategia concreta mediante una referencia a la estrategia necesaria. Puede definir una interfaz que permita a la estrategia el acceso a sus datos en caso de que fuese necesario el intercambio de información entre el contexto y la estrategia. En caso de no definir dicha interfaz, el contexto podría pasarse a sí mismo a la estrategia como parámetro.
Estrategia (Strategy): Declara una interfaz común para todos los algoritmos soportados. Esta interfaz será usada por el contexto para invocar a la estrategia concreta.
EstrategiaConcreta (ConcreteStrategy): Implementa el algoritmo utilizando la interfaz definida por la estrategia.

## Colaboraciones

Es necesario el intercambio de información entre estrategia y contexto. Este intercambio puede realizarse de dos maneras:
* Mediante parámetros en los métodos de la estrategia.
* Mandándose, el contexto, a sí mismo a la estrategia.
Los clientes del contexto lo configuran con una estrategia concreta. A partir de ahí, solo se interactúa con el contexto.

## Consecuencias

La herencia puede ayudar a factorizar las partes comunes de las familias de algoritmos (sustituyendo el uso de bloques de instrucciones condicionales). En este contexto es común la aparición conjunta de otros patrones como el patrón plantilla.
El uso del patrón proporciona una alternativa a la extensión de contextos, ya que puede realizarse un cambio dinámico de estrategia.
Los clientes deben conocer las diferentes estrategias y debe comprender las posibilidades que ofrecen.
Como contrapartida, aumenta el número de objetos creados, por lo que se produce una penalización en la comunicación entre estrategia y contexto (hay una indirección adicional).

## Implementación

Entre las posibilidades disponibles a la hora de definir la interfaz entre estrategia y contexto, están:
* Pasar como parámetro la información necesaria para la estrategia implica un bajo acoplamiento y la posibilidad de envío de datos innecesarios.
* Pasar como parámetro el contexto y dejar que la estrategia solicite la información que necesita supone un alto acoplamiento entre ellos.
* Mantener en la estrategia una referencia al contexto (similar al anterior).
También puede ocurrir que se creen y se utilicen los objetos estrategia en el contexto solo si es necesario, en tal caso las estrategias serán opcionales.

## Ejemplo

Lo importante de esta clase es que cada una de las estrategias que diseñemos tendrá que sobrescribir el método dibujar y proveer un algoritmo concreto para dicha estrategia.
El Contexto es la clase que decide qué estrategia utilizar en cada momento, la decisión se puede realizar mediante algún parámetro que le envía el cliente aunque como hemos dicho puede ser él mismo el que elija la estrategia más adecuada :
Como podemos comprobar el funcionamiento de este patrón es muy simple y el añadir nuevas estrategias a nuestro programa es muy sencillo y apenas implica modificación de código alguna.

## Ejemplos en varios lenguajes
### Python

Python ya lo implementa internamente y no se puede programar explícitamente: Este es un ejemplo con GUI

### C# 3.0

En C# 3.0, pueden usarse "expresiones lambda" para hacer lo mismo que en el ejemplo en Python.

### C#
### Perl

Perl lo tiene ya implementado y no se puede programar explícitamente:
El patrón de estrategia puede implementarse formalmente mediante Moose: