Intención: Define un conjunto de clases que representan comportamientos similares: se trata de hacer lo mismo, pero de diferente manera. Permite que un algoritmo varíe independientemente de los clientes que lo utilizan, y puedan intercambiarlos en tiempo de ejecución.
También conocido como: Polici, patrón estrategia.
Aplicabilidad: Se utiliza este patrón cuando:
Muchas clases relacionadas difieren sólo en su comportamiento.
Se necesita diferentes variantes de un algoritmo.
Se presentan muchos condicionales en el código, es posble que sea necesario aplicar este patrón.
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.
Estructura:
Participantes:
Context: es el responsable de crear y mantener una referencia a una estrategia concreta.
Strategy: es quien declara la interfaz común a todos los algoritmos soportados. Mediante esta interfaz, el contexto puede llamar a un algoritmo concreto.
Concrete Strategy: es quien realmente implementa el argoritmo.
Colaboraciones:
Context-Strategy: El contexto debe brindar a Strategy todos los datos que requiera el algoritmo. Incluso, el contexto puede pasar una referencia de si mismo, para permitirle a la estrategia hacer callback.
Client-Context:Los clientes del contexto lo configuran con una estrategia concreta
Consecuencias:
Puede aparecer lógica bastante parecida entre las Concrete Strategies. La herencia puede ayudar a factorizar las partes comunes de las familias de algoritmos.
Si bien algo similar a este patrón podría hacerse con subclases que hereden del contexto, encapsular el algoritmo en clases de estrategias separadas permite variar el algoritmo independientemente del contexto, por lo que es más fácil de cambiar, entender y extender.
Las estrategias eliminan las sentencias condicionales.
Provee diferentes implementaciones de un mismo comportamiento.
Los clientes deben conocer las diferentes estrategias y debe comprender las posibilidades que ofrecen.
Comunicación sobrecargada: algunas ConcreteStrategies no utilizarán todos los parámetros, e incluso puede que alguna implementación no utilice ninguno.
Menor eficiencia. Aumenta el número de objetos creados.
Implementación:
Definir la relación context-strategy. Ya sea
pasando valores por parámetro, con la posibilidad de envío de datos innecesarios.
pasando el contexto como parámetro, que supone un alto acoplamiento entre clases (a tal punto de parecer una única clase)
Mantener en la estrategia una referencia al contexto (podría ser un contexto Singleton).
Se podría definir una estrategia por defecto, para ahorrarle decisiones al cliente. Esto hace que la asignación de una estrategia sea opcional.
Patrones relacionados:
Template Method. Una intención similar pero haciendo uso de la herencia en lugar de delegación
Flyweight. Útil para aminorar los efectos del aumento de la población de objetos
Motivación:
Dividir un flujo de texto en líneas.
* El cliente **no siempre querrá leer un archivo,** por lo tanto tener una clase enorme podría resultar poco útil.
* Existen diferentes algoritmos que permiten leer texto desde un archivo, y ponerlos a todos en la misma clase **será muy grande y difícil de mantener**.
* Es **difícil añadir nuevos algoritmos o modificar** **los existentes** son una parte integral de una sola clase.
Pagar un servicio mediante diferentes medios. Problemas:
Existen diferentes algoritmos que permiten registrar una transacción por difeerentes medios. Por ejemplo, mediante tarjeta de crédito, mediante efectivo, mediante PagoFácil... El cliente no pagará con todos los medios de pago. Sólo elegirá uno.
Si todos los algoritmos estuviesen en la misma clase, la misma sería muy grande y difícil de mantener.
Es difícil añadirnuevos algoritmos o modificarlos existentes si son parte de una sola clase.
Dibujar un tipo de recorrido en un mapa, de acuerdo al medio de transporte elegido.
Existen diversos algoritmos a implementar, seún el usuario recorra un sitio a pie, en colectivo o en auto. Sin embargo, el usuario sólo elegirá un medio.
Si todos los algoritmos estuviesen en la misma clase, la misma sería muy grande y difícil de mantener.
Es difícil añadirnuevos algoritmos o modificarlos existentes si son parte de una sola clase.
