Commutateur d'instruction dans une instruction de commutateur?

Question

Je dois évaluer plusieurs conditions. Dans mon cas, je dois faire quelque chose comme ceci:

switch(id) 
{ 
    case 5: 
     // switch some other cases here 
    case 6: 
     // set some value 
    ... 
} 

Est-il bon d'avoir un autre interrupteur en cas 5? Si non, quoi de mieux? Vous avez des déclarations if?

Answer 1

J'appellerais une fonction qui était spécifique au cas 5, alors avoir le cas de commutateur dans cette fonction. Par exemple:

switch(id) 
{ 
    case 5: 
     functionFiveSpecific(id); 
    case 6: 
     // set some value 
    ... 
} 

La fonction spécifique pour le cas 5:

private void functionFiveSpecific(id) 
{ 
    // other switch in here 
} 

Bien que

Il est fortement recommandé d'éviter l'utilisation des états de commutation si possible. Avoir une lecture here.

Answer 2

Je voudrais appeler une fonction et passer dans les cas supplémentaires et dans la fonction faire un cas de commutation sur eux. Rend le code plus propre. Une autre méthode que j'utilise souvent est en effet imbriquée si est

Answer 3

La seule chose qui pourrait être mal avec elle est que cela pourrait nuire à la lisibilité:

switch(id) 
{ 
    case 5: 
    { 
     switch (somethingElse) 
     { 
      case 1: 
       // blah... 
     } 
    } 
    case 6: 
     // set some value 
    ... 
} 

Vous pouvez améliorer cela en déplaçant la section imbriquée dans une méthode:

switch(id) 
{ 
    case 5: 
     Foo(); 
     break; 
    case 6: 
     // set some value 
    ... 
} 

Answer 4

Les instructions de commutation ne sont pas une mauvaise pratique. Les instructions de commutation imbriquées peuvent être désordonnées à regarder. Peut-être pensez-vous à intégrer l'instruction switch imbriquée dans une autre méthode pour améliorer la clarté.

Answer 5

Utiliser le polymorphisme si possible. Cela rendrait votre code beaucoup plus propre.

Answer 6

Une meilleure pratique consiste à encapsuler les différents comportements de manière polymophique à l'intérieur de classes différentes et essayer d'éviter les instructions de commutation si possible. Ceci n'est pas toujours possible, et si vous devez utiliser des instructions switch, je ne mettrais pas une autre instruction switch imbriquée (ou une collection d'instructions if) mais aurais probablement un appel de méthode qui contiendrait cette logique.

Si vous postez un peu plus de détails sur ce que vous essayez de faire, nous serons peut-être en mesure d'offrir de meilleures suggestions.

Answer 7

Dès que vous commencez à imbriquer votre Cyclomatic complexity commence à augmenter. En fonction de la complexité de vos commutateurs imbriqués, cela peut être amusant à maintenir. Vous voudrez peut-être réfléchir au déplacement du second commutateur imbriqué vers une fonction qui lui est propre.Par exemple

switch (order.Status) 
{ 
    case OrderStatus.New: 
     // Do something to a new order; 
     break; 

    ... 

    case OrderStatus.ReadyToShip 
     // Process Shipping Instructions 
     ShipOrder(order); 
     break; 
} 

et si vous aviez un commutateur en fonction du type d'expédition payé pour

void ShipOrder(Order order) 
{ 
    switch (order.ShippingMethod) 
    { 
    } 
} 

En déplaçant la deuxième instruction switch de la première, il est plus facile à entretenir, et peut également être testé isolément

Answer 8

Éviter! Essayez de refactoriser votre code pour éliminer les cas de commutation. Les instructions de changement pour les comportements peuvent être refactorisées dans Strategy Pattern.