LIBRO DE PATRONES ORIENTADOS A OBJETOSPATRON ESTRATEGIA

PROPOSITOdefine una familia de algoritmos, encapsula cada uno de ellos y los hace intercambiables. Permite que un algoritmo vare independientemente de los clientes que los usan.

TAMBIN CONOCIDO COMOpolicy (politica)

MOTIVACINExisten muchos algoritmos para dividir en lneas de flujo de texto. Codificar dichos algoritmos en las clases que los usan no resulta una buena prctica por varias razones: Los clientes que necesitan dividir el texto en lneas se vuelve ms complejos si tienen que incluir dicho cdigo, lo que hace ms grandes y mas dificiles de mantener, sobre todo si permiten varios algoritmos diferentes de divisin en lineas. Los distintos algoritmos sern apropiados en distintos momentos. No tenemos pro qu permitir multiples algoritmos si no los vamos a usar todos. Es dificil aadir nuevos algoritmos o modificar los existentes cuando la division en lneas es parte integrar de un cliente.Estos problemas pueden evitarse definiendo clases que encapsulen los diferentes algoritmos de division en lineas. Un algoritmo asi encapslado se denomina una estrategia.

Supongamos que una clase Composicion debe mantener y actualizar los saltos de lnea del texto mostrado en el visor. Las estrategias de divisin en lneas no estn implementadas en la clase Composicion. En vez de eso, se implementan separadamente por las subclases de la clase abstracta Componedor. Las subclases Componedor implementan diferentes estrategias:

ComponedorSimple : implementa una estrategia simple que calcula un salto de linea cada vez. ComponedorTeX: implementa el algoritmo TeX para buscar los saltos de lnea. Esta estrategia trata de optimizar los saltos de lnea globalmente, es decir, un parrafi cada vez. ComponedorMatriz: implementa una estrategia que selecciona los saltos de linea de modo que cada fila tenga un numero determinado de elementos. Es util para dividir una serie de iconos en filas por ejemplo.Una composicion mantiene una referencia a un objeto Componedor. Cada vez que una Composicion vuelve a formatear su texto, reenva esta responsabilidad a su objeto Componedor. El cliente de Composicion especifica qu Componedor debera usarse, y dicho Componedor ser instalado en la Composicion.APLICABILIDADsese el patron Strategy cuando: muchas clases relacionadas difieren slo en su comportamiento. Las estrategias permiten configurar una clase con un determinado comportamiento entre muchos posibles. Se necesitan distintas variantes de un algoritmo. Por ejemplo, podriamos definir algoritmos que reflejasen distintas soluciones de compromiso entre tiempo y espacio. Pueden usarse estrategias cuando estas variantes se implementan como una jerarquia de clases de algoritmos. Un algoritmo usa datos que los clientes no deberan conocer. sese el patron Strategy para evitar exponer estructuras de datos complejas y dependientes del algoritmo. Una clase define muchos comportamientos, y stos se representan como mltiples sentencias condicionales en sus operaciones. En vez de tener muchos condicionales, podemos mover las ramas de stos a su propia clase Estrategia.

ESTRUCTURA

PARTICIPANTES Estrategia (Componedor) declara una interfaz comn para todos los algoritmos permitidos. El contexto usa esta interfaz para llamar al algoritmo definido por una EstructuraConcreta. EstrategiaConcreta(ComponedorSimple, ComponedorTeX, ComponedorMatriz)

Contexto(Composicion): 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.

COLABORACIONES Estrategia y Contexto interactuan para implementar el algoritmo elegido. Un contexto puede pasar a la estrategia todos los datos requeridos por el algoritmo cada vez que se llama a ste. Otra alternativa es que el contexto se pase a s mismo como argumento de las operaciones de Estrategia. Esto permite a la estrategia hacer llamadas al contexto cuando sea necesario. Un contexto redirige peticiones de los clientes a su estrategia. Los clientes normalmente cran un objeto EstrategiaConcreta, el cual pasan al contexto; por tanto, los clientes interactuan exclusivamente con el contexto. Suele haber una familia de clases EstrategiaConcreta a elegir por el cliente. CONSECUENCIASEl patron Strategy presenta las siguientes ventajas e inconvenientes:

1. familias de algoritmos relacionados. Las jerarquas de clases Estrategia definen una familia de algoritmos o comportamientos para ser utilizados por los contextos. La herencia puede ayudar a sacar factor comn de la funcionalidad de estos algoritmos.2. Una alternativa a la herencia. La herencia ofrece otra forma de permitir una variedad de algoritmos o comportamientos. Se puede heredar directamente de una clase Contexto para proporcionar diferentes comportamientos. Pero esto liga el comportamiento al Contexto, mezclando la implementacin del algoritmo con la del Contexto, lo que hace que ste sea ms difcil de comprender, mantener y extender. Y no se puede modificar el algoritmo dinmincamente. Acabaremos teniendo muchas clases relacionadas cuya nica diferencia es el algoritmo o comportamiento que utilizan. Encapsular el algoritmo en clases Estrategia separadas nos permite variar el algoritmo independiente de su contexto, hacendolo ms dificil de cambiar, comprender y extender.3. Las estrategias eliminan las sentencias condicionales. El patron Strategy ofrece una alternativa a las sentencias condicionales para seleccionar el comportamiento deseado. Cuando se juntan muchos comportamientos en una clase es dificil no usar sentencias condicionales para seleccionar el comportamiento correcto. Encapsular el comportamiento en clases Estrategia sepradas elimina estas sentencias condicionales.Por ejemplo , sin estrategias, el codigo oara dividir un texto en lineas podria parecerce a: