Tratando con declaraciones de interruptor anidado si entonces else/anidado

Question

¿Hay algún patrón de diseño/método/forma de eliminar las condiciones anidadas si entonces/condiciones?

Recuerdo que encontré algunos métodos utilizados por las personas de Google enumeradas en una publicación de blog del código de Google. Parece que no puede encontrarlo ahora aunque

Answer 1

Desea utilizar una refactorización que reemplaza un condicional utilizando una clase polimórfica. Para example.

O aquí es otra example

En esencia, el ideal es muy simple de crear una jerarquía de objetos, y se mueven los distintos comportamientos en un método sobreescrito. Todavía necesitará un método para crear la clase correcta, pero esto se puede hacer usando un patrón de fábrica.

Editar

quiero añadir que esto no es una solución perfecta en todos los casos. Como (olvidé su nombre, lo siento) señaló en mis comentarios, algunas veces esto puede ser un dolor especialmente si tiene que crear un modelo de objeto solo para hacer esto. Este refactorización excells si tienen esta:

function doWork(object x) 
{ 

    if (x is a type of Apple) 
    { 
     x.Eat(); 

    } else if (x is a type of Orange) 
    { 
     x.Peel(); 
     x.Eat(); 
    } 

} 

Aquí puede refactorizar el interruptor en algún nuevo método que cada fruta manejará.

Editar

Como alguien ha señalado, ¿cómo crear el tipo correcto para entrar en DoWork, hay más formas de resolver este problema, entonces yo podría enumerar PROBally por lo que algunas formas básicas. El primero y más sencillo (y sí va en contra de esta pregunta) es un interruptor:

class FruitFactory 
{ 
    Fruit GetMeMoreFruit(typeOfFruit) 
    { 
     switch (typeOfFruit) 
     ... 
     ... 
    } 
} 

Lo bueno de este enfoque es que es fácil de escribir, y es generalmente el primer método que utilizo. Si bien todavía tiene una instrucción switch está aislada de un área de código y es muy básica, todo lo que devuelve es un n objeto. Si solo tiene un par de objetos y no están cambiando, esto funciona muy bien.

Otros patrones más compelx que puedes mirar es un Abstract Factory. También podría crear dinámicamente Fruit si su plataforma lo admite. También podría usar algo como el Provider Pattern. Lo que esencialmente para mí significa que configuras tu objeto y luego tienes una fábrica que, según la configuración y una clave que le das a la fábrica, crea dinámicamente la clase correcta.

Answer 2

No dice qué idioma está utilizando, pero si está utilizando un lenguaje OO como C++, C# o Java, a menudo puede usar funciones virtuales para resolver el mismo problema que está resolviendo actualmente con una declaración switch, y de una manera más extensible. En el caso de C++, comparar:

class X { 
public: 
    int get_type();  /* Or an enum return type or similar */ 
    ... 
}; 

void eat(X& x) { 
    switch (x.get_type()) { 
    TYPE_A: eat_A(x); break; 
    TYPE_B: eat_B(x); break; 
    TYPE_C: eat_C(x); break; 
    } 
} 

void drink(X& x) { 
    switch (x.get_type()) { 
    TYPE_A: drink_A(x); break; 
    TYPE_B: drink_B(x); break; 
    TYPE_C: drink_C(x); break; 
    } 
} 

void be_merry(X& x) { 
    switch (x.get_type()) { 
    TYPE_A: be_merry_A(x); break; 
    TYPE_B: be_merry_B(x); break; 
    TYPE_C: be_merry_C(x); break; 
    } 
} 

con

class Base { 
    virtual void eat() = 0; 
    virtual void drink() = 0; 
    virtual void be_merry() = 0; 
    ... 
}; 

class A : public Base { 
public: 
    virtual void eat() { /* Eat A-specific stuff */ } 
    virtual void drink() { /* Drink A-specific stuff */ } 
    virtual void be_merry() { /* Be merry in an A-specific way */ } 
}; 

class B : public Base { 
public: 
    virtual void eat() { /* Eat B-specific stuff */ } 
    virtual void drink() { /* Drink B-specific stuff */ } 
    virtual void be_merry() { /* Be merry in an B-specific way */ } 
}; 

class C : public Base { 
public: 
    virtual void eat() { /* Eat C-specific stuff */ } 
    virtual void drink() { /* Drink C-specific stuff */ } 
    virtual void be_merry() { /* Be merry in a C-specific way */ } 
}; 

La ventaja es que se pueden añadir nuevos Base clases derivada de D, E, F y así sucesivamente sin tener que tocar cualquier código que solo trata con punteros o referencias a Base, por lo que no hay nada que pueda desactualizarse de la misma manera que una declaración switch en la solución original.(La transformación se ve muy similar en Java, donde los métodos son virtuales por defecto, y estoy seguro de que también se ve similar en C#). En un proyecto grande, este es un enorme ganabilidad de mantenimiento.

Answer 3

¿Has leído this en el código de flecha de aplanamiento de Coding Horror?

Puede reemplazar throw con return o goto si está utilizando un idioma sin excepciones.

Answer 4

De hecho, escribí sobre cómo resolver estos problemas en mi blog en abril de 2008. Eche un vistazo a here y dígame lo que piensa.

Te recomiendan:

1. Uso de polimorfismo para obtener el comportamiento correcto en tiempo de ejecución que necesita sin sentencias condicionales.

2. Tome todas sus declaraciones condicionales y muévalas a algún tipo de "fábrica" ​​que le proporcionará el tipo apropiado en tiempo de ejecución.

3. Ya ha terminado. ¿No fue tan fácil? :)

Si desea ver un ejemplo de código real sobre cómo transformar su código, diríjase a mi blog.

P.S. Este no es un intento barato de auto promoción; He sido un usuario de SO durante mucho tiempo, y esta es la primera vez que me he vinculado a mi blog, y solo lo he hecho porque creo que es relevante.

Answer 5

¿Estabas pensando en el video de Google "The Clean Code Talks -- Inheritance, Polymorphism, & Testing"? Discute los enfoques para usar técnicas orientadas a objetos para eliminar si/cambiar condicionales.

Answer 6

Es posible que desee mirar el Strategy Pattern, donde en lugar de poner una larga cadena de ifs con condiciones vinculadas, se abstrae cada condición a un objeto diferente, cada uno definiendo cuál es su comportamiento específico.

La clase que define esos objetos implementará una interfaz que será llamada por el objeto principal.

Answer 7

¿Qué tal:

/* Code Block 1... */ 

if(/* result of some condition or function call */) 
{ 
    /* Code Block 2... */ 

    if(/* result of some condition or function call */) 
    { 
     /* Code Block 3... */ 

     if(/* result of some condition or function call */) 
     { 
     /* Code Block 4... */ 
     } 
    } 
} 

Se convierte en esto:

/* Code Block 1... */ 
IsOk = /* result of some condition or function call */ 

if(IsOK) 
{ 
    /* Code Block 2... */ 
    IsOk = /* result of some condition or function call */ 
} 

if(IsOK) 
{ 
    /* Code Block 3...*/ 
    IsOk = /* result of some condition or function call */ 
} 

if(IsOK) 
{ 
    /* Code Block 4...*/ 
    IsOk = /* result of some condition or function call */ 
} 

/* And so on... */ 

Puede, por supuesto, si alguna vez regreso Isok se convierte en falsa, en su caso.