You are on page 1of 4

Estudio del Patrón Strategy

1. Intención
Definir una familia de algoritmo, encapsulándolos y haciéndolos intercambiables entre sí. Permite que un algoritmo varíe independientemente de los clientes que lo utilicen.

2. Otros nombres
También se le conoce como patrón “Policy” (Política)

3. Motivación
Existen (por ejemplo) múltiples estrategias para ordenar una lista y el incluir el código de estos algoritmos en las clases que los utilizan no es una buena práctica por diversos motivos:  El tamaño de las clases clientes aumenta y se hacen más difíciles de mantener (sobre todo si se necesitan varios métodos de ordenación). Algunas formas de ordenación son interesantes sólo en ciertas situaciones (por ejemplo, la ordenación por conteo es muy interesante en algunas ocasiones, pero totalmente inútil en otras, o puede interesar usar una estrategia u otra en función del “grado de desorden” de la lista) y es absurdo el permitir varios algoritmos si algunos no van a utilizarse. Resulta complicado añadir nuevos algoritmos de ordenación o modificar los existentes si su código es parte de la clase que los utiliza.

Esta situación 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 patrón Strategy

en este caso. pero las estrategias de ordenación no se encuentran implementadas en esta clase.   5. Por el contrario. El ordenador deseado debe ser añadido a la Lista y para cambiar el método de ordenación no hay más que cambiar el ordenador. Estos comportamientos pueden extraerse a Strategies separadas. Estructura package Data[ ejemplo ] Contexto +interfazContexto() -estrategia Estrategia +interfazAlgoritmo() EstrategiaConcretaA +interfazAlgoritmo() EstrategiaConcretaB +interfazAlgoritmo() EstrategiaConcretaC +interfazAlgoritmor() Estructura general patrón Strategy 2 . El algoritmo usa datos que los clientes no deben conocer.La clase lista representa un conjunto de elementos que deben ser ordenados de acuerdo a algún criterio. cada vez que quiere ordenarse la lista. Aplicabilidad Este patrón puede utilizarse cuando:   Muchas clases relacionadas sólo se diferencian en el comportamiento. 4. De este modo. Una clase tiene muchos comportamientos diferentes representados como múltiples sentencias condicionales. teniendo la lista una referencia a un ordenador concreto (Cada ordenador. estas estrategias están implementadas en subclases de la clase abstracta ordenador. El patrón strategy oculta las estructuras de datos. Se necesitan diversas variantes de un algoritmo (merge sort e in place merge sort por ejemplo). se delega la responsabilidad en el ordenador. utiliza el algoritmo de ordenación especificado en el nombre).

En el ejemplo de las ordenaciones. Se eliminan sentencias condicionales al extraer diferentes comportamientos en estrategias. y el In-place mergesort. 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. creando familias. Participantes  Estrategia (Ordenador) o Ofrece una interfaz común a todos los algoritmos que realizan la funcionalidad. que tiene una complejidad tanto espacial como temporal de . A     Y los siguientes inconvenientes:  El cliente debe conocer y entender las estrategias disponibles antes de escoger una. Para realizar la llamada a la estrategia concreta. que tiene complejidad temporal de (aunque es más rápido que los algoritmos cuadráticos clásicos) y complejidad espacial . una interfaz para que el objeto estrategia acceda a sus datos. Puede definir. El contexto puede pasar a la estrategia los datos necesarios para la aplicación 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 ejecución del algoritmo (requiere interfaz). Ventajas e inconvenientes Este patrón presenta las siguientes ventajas:  Permite sacar factor común de la funcionalidad de los algoritmos a través de la herencia. puede escogerse entre el mergesort clásico. Encapsular el algoritmo con independencia del contexto hace que sea más fácilmente entendible y mantenible. 7. Mantiene una referencia al objeto estrategia. Permite elegir entre diferentes implementaciones de un mismo algoritmo para escoger la más apropiada en cada momento de acuerdo a las necesidades de eficiencia espacial o temporal.6. 3 .  Estrategia concreta (OrdenadorMerge. Esta interfaz es utilizada por el contexto. si fuera necesario.

John Vlissides. por tanto puede que parte de la información recibida por la interfaz no sea utilizada por alguna estrategia concreta y el contexto esté inicializando parámetros que no van a utilizarse. Richard Helm. 4 . Ralph Johnson. Elements of Reusable Object-Oriented Software. Este patrón aumenta el número de objetos del sistema. Erich Gamma. 1994. Addison Wesley (GoF. Esto puede resolverse utilizando objetos sin estado para las estrategias. 8.Gang of Four).  La interfaz de estrategia es compartida por todas las estrategias completas. Addison Wesley. Bibliografía Design Patterns.