Cuándo elegir Estrategia sobre el polimorfismo al refaccionar la declaración del interruptor

Question

¿Puede darme una razón específica sobre cuándo elegir stratergy sobre polymorphsim y viceversa?

¡Muchas gracias!

Answer 1

Un criterio que es importante es si el polimorfismo crearía un acoplamiento que la estrategia evitaría. Por ejemplo, si implementar un método "save()" para un árbol de clases significa usar funciones de E/S de bajo nivel, entonces, si usa polimorfismo, el árbol de clases se acoplaría al sistema de E/S, mientras que no lo era t antes Sin embargo, si usa el patrón de estrategia, los objetos de estrategia servirán como "buffer" y evitarán que el árbol de clases dependa de E/S.

Answer 2

Inicia su aplicación con nulo.

El siguiente paso es código sin procesar con polimorfismo.

Con casos básicos, puede permanecer de esa manera, eso no es un problema.

Si desea que su aplicación sea más flexible, esté preparada para los cambios y planee continuar desarrollándola, es hora de buscar algunos patrones de diseño, la estrategia es una de las que debería pensar, cuando el polimorfismo está dando algunos problemas

---

Intención de la estrategia:

definir una familia de algoritmos, encapsula cada uno, y los hace intercambiables. La estrategia permite que el algoritmo varíe independientemente de los clientes que lo usan.

---

La motivación para el uso de estrategias: existen

Muchos algoritmos para romper una corriente de texto en lines.Hard-cablear todas este tipo de algoritmos en las clases que les exigen no es deseable por varias razones :

· Los clientes que necesitan un corte de línea se vuelven más complejos si incluyen el código de corte de línea . Eso hace que los clientes sean más grandes y más difíciles de mantener, , especialmente si son compatibles con múltiples algoritmos de salto de línea.

· Distintos algoritmos serán apropiados en momentos diferentes. No queremos que admita múltiples algoritmos de salto de línea si no los usamos todos.

· Es difícil agregar nuevos algoritmos y modificar los ya existentes cuando el salto de línea es una parte integral de un cliente. Podemos evitar estos problemas definiendo clases que encapsulen diferentes algoritmos de salto de línea . Un algoritmo que está encapsulado de esta manera se llama una estrategia.

---

Consecuencias:

1. Las familias de algorithms.Hierarchies relacionados de clases Estrategia definen una familia de algoritmos o comportamientos para los contextos de reutilizar. La herencia puede ayudar a a descartar la funcionalidad común de los algoritmos.

2. Una alternativa a las subclases.La herencia ofrece otra manera de admitir una variedad de algoritmos o comportamientos. Puede subclasificar una clase de contexto directamente para darle diferentes comportamientos. Pero esto dificulta el comportamiento en Context. Mezcla la implementación del algoritmo con Context, lo que hace que el contexto sea más difícil de comprender, mantener y ampliar. Y no puede variar el algoritmo dinámicamente. Terminas con muchas clases relacionadas cuya única diferencia es el algoritmo o comportamiento que emplean . Encapsular el algoritmo en clases de estrategia separadas le permite variar el algoritmo independientemente de su contexto, lo que facilita el cambio, la comprensión y la extensión .

3. Las estrategias eliminan declaraciones condicionales. El patrón de estrategia ofrece una alternativa a las instrucciones condicionales para seleccionar el comportamiento deseado. Cuando se agrupan diferentes comportamientos en una clase, es difícil evitar el uso de declaraciones condicionales para seleccionar el comportamiento correcto. Encapsular el comportamiento en clases de estrategia separadas elimina estas instrucciones condicionales .