STRATEGY

• Define una familia de algoritmos,

encapsula cada uno de ellos y los hace
intercambiables. Permite que un algoritmo
varíe independientemente de los clientes
que los usan
• En base a un parámetro, que puede ser
cualquier objeto, permite a una aplicación
decidir en tiempo de ejecución el
algoritmo que debe ejecutar.
• Implementar igual método con distintas
estrategias

DISEÑO DE SISTEMAS
STRATEGY: ESTRUCTURA

DISEÑO DE SISTEMAS
STRATEGY: ESTRUCTURA

• Estrategia (SortStrategy)
declara una interfaz común a todos los algoritmos
permitidos. El Contexto usa esta interfaz para llamar al
algoritmo definido por una EstrategiaConcreta

• EstrategiaConcreta (QuickSort, ShellSort, mergesort)

implementa el algoritmo usando la interfaz Estrategia

• Contexto (SortedList)
se configura con un objeto EstrategiaConcreta.Mantiene una
referencia a un objeto Estrategia. Puede definir una interfaz
que permita a la Estrategia acceder a sus datos

DISEÑO DE SISTEMAS
STRATEGY

Imaginemos una biblioteca de un instituto educativo que presta

libros a los alumnos y profesores. Imaginemos que los alumnos
pueden asociarse a la biblioteca pagando una mensualidad. Con
lo cual un libro puede ser prestado a Alumnos, Socios y
Profesores.
Por decisión de la administración, a los socios se les prestará el
libro más nuevo, luego aquel que se encuentre en buen estado y,
por último, aquel que estuviese en estado regular.
En cambio, si un Alumno pide un libro, ocurre todo lo contrario.
Por último, a los profesores intentarán otorgarles libros buenos,
luego los recién comprados y, por último, los regulares. Este caso
es ideal para el patrón Strategy, ya que dependiendo de un
parámetro (el tipo de persona a la que se le presta el libro) puede
realizar una búsqueda con distintos algoritmos.

DISEÑO DE SISTEMAS
STRATEGY

Podemos tener 3 métodos para cada estrategia (algoritmo) de

préstamos:
Clase1: BuenoNuevoRegularStrategy
Clase 2: NuevoBuenoRegularStrategy
Clase 3: RegularBuenoNuevoStrategy
class Patron Strategy

«interface»
LibroStrategy LibroFinder
+ findLibro() : void
+ findLibro() : void

BuenoNuev oRegularStrategy Nuev oBuenoRegularStrategy RegularBuenoNuev oStrategy

+ findLibro() : void + findLibro() : void + findLibro() : void

DISEÑO DE SISTEMAS
STRATEGY

DISEÑO DE SISTEMAS
STRATEGY

8
STRATEGY VS. STATE
Se suele decir que los patrones Strategy y State son hermanos que
fueron separados al nacer. Esto se debe a que sus razones de ser
son muy parecidas: modificar el funcionamiento de un objeto en
tiempo de ejecución de forma transparente a través de un proceso
de composición.
La diferencia fundamental, sin embargo, se encuentra en que el
patrón Strategy tiene como objetivo proporcionar alternativas
para realizar una misma tarea, aunque ésta sea de alto nivel, es
decir: el patrón Strategy es adecuado cuando queremos, por
ejemplo, serializar un objeto. Cada una de las implementaciones
encapsulará una forma distinta de serialización: binaria, Base64,
como un fichero XML, JSON, etc.

DISEÑO DE SISTEMAS
STRATEGY VS. STATE
State, por su parte, tiene su razón de ser en proporcionar
comportamientos distintos cuando la aplicación se encuentra
en estados distintos. Con este patrón, la clase que implemente
nuestro State realizará operaciones distintas dependiendo de su
estado, no proporcionará “varias formas de hacer lo mismo”. Por
ello, Strategy y State son patrones distintos, aunque muy
similares: Strategy encapsula el algoritmo, mientras que State
encapsulará un comportamiento que variará dependiendo del
estado en el que se encuentre el programa.

DISEÑO DE SISTEMAS