Patrón de estrategia | Serie 1 (Introducción)

Como siempre, aprenderemos este patrón definiendo un problema y usando el patrón de estrategia para resolverlo. Supongamos que estamos construyendo un juego «Street Fighter». Para simplificar, suponga que un personaje puede tener cuatro movimientos: patear, golpear, rodar y saltar. Cada personaje tiene movimientos de patadas y puñetazos, pero rodar y saltar son opcionales. ¿Cómo modelarías tus clases? Supongamos que inicialmente utiliza la herencia y abstrae las características comunes en una clase de Luchador y deja que otros personajes subclasifiquen la clase de Luchador .

La clase de combate tendremos la implementación predeterminada de las acciones normales. Cualquier personaje con movimiento especializado puede anular esa acción en su subclase. 

¿Cuáles son los problemas con el diseño anterior?

¿Qué pasa si un personaje no realiza un movimiento de salto? Todavía hereda el comportamiento de salto de la superclase. Aunque puede anular el salto para no hacer nada en ese caso, es posible que deba hacerlo para muchas clases existentes y encargarse de eso también para las clases futuras. Esto también dificultaría el mantenimiento. Así que no podemos usar la herencia aquí.

¿Qué pasa con una interfaz?

Echa un vistazo al siguiente diseño:

Es mucho más limpio. Eliminamos algunas acciones (que algunos personajes podrían no realizar) de la clase Fighter y creamos interfaces para ellas. De esa manera, solo los personajes que se supone que deben saltar implementarán JumpBehavior.

¿Cuáles son los problemas con el diseño anterior?

El principal problema con el diseño anterior es la reutilización de código. Dado que no existe una implementación predeterminada del comportamiento de saltar y rodar, es posible que tengamos duplicidad de código. Puede que tenga que reescribir el mismo comportamiento de salto una y otra vez en muchas subclases.

¿Cómo podemos evitar esto?

¿Qué pasaría si hiciéramos las clases JumpBehavior y RollBehavior  en lugar de la interfaz? Bueno, entonces tendríamos que usar la herencia múltiple que no está soportada en muchos idiomas debido a muchos problemas asociados con ella.

Aquí el patrón de estrategia viene a nuestro rescate. Aprenderemos cuál es el patrón de estrategia y luego lo aplicaremos para resolver nuestro problema.

Definición:

Wikipedia define el patrón de estrategia como:

“En la programación informática, el  patrón de estrategia  (también conocido como  patrón de política ) es un patrón de diseño de software que permite seleccionar el comportamiento de un algoritmo en tiempo de ejecución. El patrón de la estrategia

• define una familia de algoritmos,
• encapsula cada algoritmo, y
• hace que los algoritmos sean intercambiables dentro de esa familia”.

 

Diagrama de clase :

Aquí confiamos en la composición en lugar de la herencia para la reutilización. El contexto  se compone de una estrategia . En lugar de implementar un comportamiento, el Contexto lo delega a la Estrategia . El contexto sería la clase que requeriría cambiar comportamientos. Podemos cambiar el comportamiento dinámicamente. La estrategia se implementa como interfaz para que podamos cambiar el comportamiento sin afectar nuestro contexto.

Tendremos una comprensión más clara del patrón de estrategia cuando lo usemos para resolver nuestro problema.

ventajas:

1. Una familia de algoritmos se puede definir como una jerarquía de clases y se puede usar indistintamente para alterar el comportamiento de la aplicación sin cambiar su arquitectura.
2. Al encapsular el algoritmo por separado, se pueden introducir fácilmente nuevos algoritmos que cumplan con la misma interfaz.
3. La aplicación puede cambiar de estrategia en tiempo de ejecución.
4. La estrategia permite a los clientes elegir el algoritmo requerido, sin usar una declaración de «cambio» o una serie de declaraciones «si no».
5. Las estructuras de datos utilizadas para implementar el algoritmo están completamente encapsuladas en las clases de estrategia. Por lo tanto, la implementación de un algoritmo se puede cambiar sin afectar la clase Contexto.

Desventajas:

1. La aplicación debe conocer todas las estrategias para seleccionar la adecuada para la situación adecuada.
2. El contexto y las clases de estrategia normalmente se comunican a través de la interfaz especificada por la clase base de estrategia abstracta. La clase base de estrategia debe exponer la interfaz para todos los comportamientos requeridos, que algunas clases de estrategia concretas podrían no implementar.
3. En la mayoría de los casos, la aplicación configura el Contexto con el objeto de Estrategia requerido. Por lo tanto, la aplicación necesita crear y mantener dos objetos en lugar de uno.

 

Lectura adicional: método de estrategia en Python

Referencias:

• Patrones de diseño Head First
• http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2007/wiki1b_8_sa
• https://en.wikipedia.org/wiki/Strategy_pattern

Este artículo es una contribución de Sulabh Kumar. Si le gusta GeeksforGeeks y le gustaría contribuir, también puede escribir un artículo y enviarlo por correo a review-team@geeksforgeeks.org. Vea su artículo que aparece en la página principal de GeeksforGeeks y ayude a otros Geeks.

Escriba comentarios si encuentra algo incorrecto o si desea compartir más información sobre el tema tratado anteriormente.