El patrón Estrategia (Strategy)
Propósito
Define una familia de algoritmos, encapsula cada uno de ellos y los hace intercambiables. Permite que un algoritmo varié independientemente de los clientes que lo usan.Aplicabilidad
Muchas clases relacionadas difieren solo en su comportamiento. Las estrategias permiten configurar una clase con un determinado comportamiento entre muchos posibles.Se necesitan distintas variantes de un algoritmo.
Un algoritmo usa daos que los clientes no deberían conocer. Use el patón Strategy para evitar exponer estructuras de datos complejas y dependientes del algoritmo
Una clase define muchos comportamientos y estos se representan como múltiples sentencias condicionales en sus operaciones. En vez de tener muchos condicionales, podemos mover las ramas de estos a sus propias clases estrategia
Estructura del Patrón de comportamiento Estrategia (GOF)
Participantes
- Estrategia (Componedor)
- Declara la interfaz común a todos los algoritmos permitidos.
- El *contexto* usa esa interfaz para llamar al algoritmo definido por una estrategia
- Estrategia Concreta
- Implementa el algoritmo concreto
- Contexto
- Instancia un objeto Estrategia Concreta
- Mantiene una referencia la un objeto estrategia (concreta)
- Puede definir una interfaz que permita a la Estrategia (concreta) acceder a sus datos
Consecuencias
- Familias de algoritmos relacionados.: Las jerarquías de clases Estrategia definen una familia de algoritmos o comportamientos
- 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 implementación del algoritmo con la del Contexto, lo que hace que éste sea más difícil de comprender, mantener y extender. Y no se puede modificar el algoritmo dinámicamente. 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 independientemente de su contexto, haciéndolo más fácil de cambiar, comprender y extender.
- Las estrategias eliminan las sentencias condicionales.: El patrón estrategia ofrece una alternativa a las sentencias condicionales para seleccionar el comportamiento deseado. Cuando se juntan muchos comportamientos en una clase es difícil no usar sentencias condicionales para seleccionar el comportamiento correcto. Encapsular el comportamiento en clases estrategias separadas elimina estas sentencias condicionales, delegando la tarea en el objeto estrategia.
- Los clientes deben conocer las diferentes estrategias.: el patrón tiene el inconveniente potencial de que un cliente debe comprender como difieren las Estrategias antes de seleccionar la adecuada. Los clientes pueden estar expuestos a cuestiones de i implementación. Por lo tanto, el patrón estrategia debería usarse solo cuando la variación del comportamiento sea relevante a los clientes.
- Costes de comunicación entre Estrategia y Contexto.: La interfaz de Estrategia es compartida por todas las clases Estrategia Concreta, ya sea el algoritmo que implementa trivial o completamente. Por lo tanto, es probable que algunos objetos Estrategia Completa no usen toda la información que reciben a través de dicha interfaz; las estrategias concretas simples pueden incluso no utilizar nada de dicha información. Esto significa que habrá veces en las que el contexto crea e inicializa parámetros que nunca e utilizan. Si esto puede ser un problema, necesitaremos un acoplamiento más fuerte entre Estrategia y Contexto
- Mayor numero de objetos.: Las estrategias aumentan el número de objetos de una aplicación. A veces se puede reducir este coste implementando estrategias como objetos sin estado que puedes ser compartida por el contexto. El contexto mantiene cualquier estad residual, pasándolo en cada petición de al objeto estrategia. Las estrategias compartidas no deberían mantener el estado entre invocaciones.
© 2002 - Teleprogramadores.com - David Hernández Tejada
No hay comentarios:
Publicar un comentario