6

Quiero crear una clase que pueda usar uno de los cuatro algoritmos (y el algoritmo a usar solo se conoce en tiempo de ejecución). Estaba pensando que el patrón de diseño de la estrategia parece apropiado, pero mi problema es que cada algoritmo requiere parámetros ligeramente diferentes. ¿Sería un mal diseño usar la estrategia, pero pasar los parámetros relevantes al constructor ?.¿Qué patrón de diseño es el más apropiado?

Aquí es un ejemplo (para simplificar, digamos que sólo hay dos algoritmos posibles) ...

class Foo 
{ 
private: 
    // At run-time the correct algorithm is used, e.g. a = new Algorithm1(1); 
    AlgorithmInterface* a; 

}; 

class AlgorithmInterface 
{ 
public: 
    virtual void DoSomething() = 0; 
}; 

class Algorithm1 : public AlgorithmInterface 
{ 
public: 
    Algorithm1(int i) : value(i) {} 
    virtual void DoSomething(){ // Does something with int value }; 
    int value; 
}; 

class Algorithm2 : public AlgorithmInterface 
{ 
public: 
    Algorithm2(bool b) : value(b) {} 
    virtual void DoSomething(){ // Do something with bool value }; 
    bool value; 
}; 
+5

En lugar de tratar de ajustar el código en algún patrón presupuesta, sólo el diseño que eso es más claro a usted (y es de esperar más clara a todos los demás) y más fácil de mantener. En otras palabras: los patrones de diseño apestan. Si * usted * encuentra una forma elegante de resolver un problema, úselo; si viola o no un patrón de diseño arbitrario es irrelevante. – GManNickG

+0

Además, si nos da un poco más (cómo se pasan estos parámetros, etc.) podemos darle una mejor respuesta. Pero al igual que parece, parece una buena solución para mí. – GManNickG

Respuesta

7

Sería un diseño válido porque el patrón Estrategia pide que se defina una interfaz y cualquier clase que la implemente sea un candidato válido para ejecutar el código de estrategia, independientemente de cómo se construya.

2

Creo que es correcto, si tiene todos los parámetros necesarios cuando se crea la nueva estrategia y lo que haces está claro para todos leyendo el código.

0

También puede pasar parámetros en el uso de una única interfaz de un bloque de memoria que contiene pares de valores clave. De esta manera, la interfaz es común entre cualquier algoritmo presente y futuro. Cada implementación de algoritmo sabría cómo decodificar los pares clave-valor en sus parámetros.

+1

¿No rompería esto la idea del patrón de estrategia, ya que el código que llama a la estrategia debería saber qué estrategia se estaba usando para saber qué pares de clave/valor aprobar? –

+0

No, esto solo afectaría la implementación de la clase de estrategia. En lugar de construir los algoritmos con interfaces únicas, sería uniforme. La interfaz de la aplicación no debería cambiar. Tal vez exista un alto costo para una pequeña cantidad de algoritmos, pero si el número puede crecer hasta docenas o más, puede ser más fácil de mantener. –

+0

@Eric, supongo que eso dependerá de si espera que los clientes siempre suministren los mismos pares clave-> valor. Por supuesto, eso plantearía la pregunta de por qué la necesidad de pares clave-> valor. –

2

Usted tiene razón con este enfoque. Sí, esta es la esencia del patrón de estrategia ... "Varíe el algoritmo independientemente de la implementación". Puedes darte un constructor genérico para pasar los parámetros que necesitas para inicializar tu clase, como una matriz de objetos.

¡Disfrútalo!

1

patrón de estrategia son útiles cuando se quiere decidir sobre el tiempo de ejecución qué algoritmo se va a utilizar.

0

en mi humilde opinión, que se enfrenta al reto ya que está confundiendo entre el aspecto creacional del algoritmo de hormigón y el funcionamiento real del algoritmo. Siempre que la interfaz 'DoSomething' permanezca igual, se puede usar Strategy Pattern. Es solo la creación del algoritmo concreto diferente que varía en su caso, que puede manejarse a través de un patrón de diseño Factory Method.

Cuestiones relacionadas