Estudio del Patrn Strategy

Borja Prez Pavn

1. Intencin
Definir una familia de algoritmo, encapsulndolos y hacindolos intercambiables entre s. Permite que un algoritmo vare independientemente de los clientes que lo utilicen.

2. Otros nombres
Tambin se le conoce como patrn Policy (Poltica)

3. Motivacin
Existen (por ejemplo) mltiples estrategias para ordenar una lista y el incluir el cdigo de estos algoritmos en las clases que los utilizan no es una buena prctica por diversos motivos: El tamao de las clases clientes aumenta y se hacen ms difciles de mantener (sobre todo si se necesitan varios mtodos de ordenacin). Algunas formas de ordenacin son interesantes slo en ciertas situaciones (por ejemplo, la ordenacin por conteo es muy interesante en algunas ocasiones, pero totalmente intil en otras, o puede interesar usar una estrategia u otra en funcin del grado de desorden de la lista) y es absurdo el permitir varios algoritmos si algunos no van a utilizarse. Resulta complicado aadir nuevos algoritmos de ordenacin o modificar los existentes si su cdigo es parte de la clase que los utiliza.

Esta situacin puede resolverse definiendo clases que encapsulen los algoritmos. Un algoritmo as encapsulado se denomina estrategia.
package Data[ ejemplo ]

Lista

-ordenador

Ordenador +ordenar()

OrdenadorMerge +ordenar()

OrdenadorInPlaceMerge +ordenar()

OrdenadorCounting +ordenar()

OrdenadorQuick +ordenar()

Diagrama de ejemplo patrn Strategy

La clase lista representa un conjunto de elementos que deben ser ordenados de acuerdo a algn criterio, pero las estrategias de ordenacin no se encuentran implementadas en esta clase. Por el contrario, estas estrategias estn implementadas en subclases de la clase abstracta ordenador, teniendo la lista una referencia a un ordenador concreto (Cada ordenador, en este caso, utiliza el algoritmo de ordenacin especificado en el nombre). De este modo, cada vez que quiere ordenarse la lista, se delega la responsabilidad en el ordenador. El ordenador deseado debe ser aadido a la Lista y para cambiar el mtodo de ordenacin no hay ms que cambiar el ordenador.

4. Aplicabilidad
Este patrn puede utilizarse cuando: Muchas clases relacionadas slo se diferencian en el comportamiento. Se necesitan diversas variantes de un algoritmo (merge sort e in place merge sort por ejemplo). El algoritmo usa datos que los clientes no deben conocer. El patrn strategy oculta las estructuras de datos. Una clase tiene muchos comportamientos diferentes representados como mltiples sentencias condicionales. Estos comportamientos pueden extraerse a Strategies separadas.

5. Estructura
package Data[ ejemplo ]

Contexto +interfazContexto()

-estrategia

Estrategia +interfazAlgoritmo()

EstrategiaConcretaA +interfazAlgoritmo()

EstrategiaConcretaB +interfazAlgoritmo()

EstrategiaConcretaC +interfazAlgoritmor()

Estructura general patrn Strategy

6. Participantes
Estrategia (Ordenador) o Ofrece una interfaz comn a todos los algoritmos que realizan la funcionalidad. Esta interfaz es utilizada por el contexto. Para realizar la llamada a la estrategia concreta.

Estrategia concreta (OrdenadorMerge, OrdenadorQuick) o Implementa el algoritmo usando la interfaz de la estrategia

Contexto (Lista) o o o Se configura con una estrategia concreta utiliza la estrategia deseada. Mantiene una referencia al objeto estrategia. Puede definir, si fuera necesario, una interfaz para que el objeto estrategia acceda a sus datos. El contexto puede pasar a la estrategia los datos necesarios para la aplicacin del algoritmo en la llamada (no es necesaria interfaz) o pasarse a s mismo en la llamada para que la estrategia concreta tome los datos que necesite en la ejecucin del algoritmo (requiere interfaz).

7. Ventajas e inconvenientes
Este patrn presenta las siguientes ventajas: Permite sacar factor comn de la funcionalidad de los algoritmos a travs de la herencia, creando familias. Encapsular el algoritmo con independencia del contexto hace que sea ms fcilmente entendible y mantenible. Se eliminan sentencias condicionales al extraer diferentes comportamientos en estrategias. Permite elegir entre diferentes implementaciones de un mismo algoritmo para escoger la ms apropiada en cada momento de acuerdo a las necesidades de eficiencia espacial o temporal. En el ejemplo de las ordenaciones, puede escogerse entre el mergesort clsico, que tiene una complejidad tanto espacial como temporal de ( log ), y el In-place mergesort, que tiene complejidad temporal de (2 ) (aunque es ms rpido que los algoritmos cuadrticos clsicos) y complejidad espacial (1).

Y los siguientes inconvenientes: El cliente debe conocer y entender las estrategias disponibles antes de escoger una. La interfaz de estrategia es compartida por todas las estrategias completas, por tanto puede que parte de la informacin recibida por la interfaz no sea utilizada por alguna estrategia concreta y el contexto est inicializando parmetros que no van a utilizarse.

Este patrn aumenta el nmero de objetos del sistema. Esto puede resolverse utilizando objetos sin estado para las estrategias.

8. Bibliografa
Design Patterns. Elements of Reusable Object-Oriented Software. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Addison Wesley (GoF- Gang of Four). Addison Wesley. 1994.