Switch Case joli ou pas ?

Bonjour,

Je me pose des questions sur la forme switch / case, et je cherche un modèle de conception OO qui la remplace.

J'ai essayé celui du visiteur, mais, s'il est très éléguant, je le trouve finalement peut intuitif à la relecture.

Il y a des choses comme Strategy, State, Bridge, mais j'ai l'impression que ils ne sont pas fait pour ça ; en fait, dans tous ces patterns, il me semble que le choix du traitement est fait par le contexte, donc par... un switch case.

Qu'en pensez-vous ?... Que faites-vous ?...

Bonjour,

bien vu la notion de "joli" !

On peut toujours remplacer un switch ou un if par un appel de methode (methode virtuelle, liaison dynamique).

du genre, pour l'affichage d'un nombre entier dans plusieurs formats :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

print (entier i, entier format) { switch (format) { case DECIMAL : printf("%d", i); break; case HEXA : printf("%xd", i); break; case BINAIRE : ...

---

peut devenir :

Code:

---

1 2	object_formater.print(i);

---

tout depend de la classe de object_formater (Abstract_Formater, dont héritent Decimal_Formater, Hexa_Formater, ...).

C'est beaucoup plus "joli", au sens OO du terme...
mais beaucoup plus lourd !

Le pattern visiteur est un moyen de "rester a peu prêt objet" en délégant des comportements a des classes externes. Utile mais attention a ne pas exporter trop de responsabilités.

En resume :
faire du joli dans les grandes lignes (surtout en début d'analyse), puis dans les détails ne pas hésiter a faire "crade". (attention quand même a rester "joli" dans l'ensemble).

Alex

Ouais c'est un peu la conclusion à laquelle j'étais arrivé, mais enfin tu m'avoueras que c'est un peu bizarre...

Il n'y a donc aucun pattern OO qui soit vraiment satisfaisant, à l'usage je parle (et non à la théorie), par rapport au switch case ?

Certes l'idée du formatter est pas mal, mais elle t'oblige à créer une classe par comportement, et par type. Si je veux qu'un véhicule respecte les feux, par exemple, alors je dois créer une classe pour chaque couleur du feu et chaque véhicule... et avec ça je ne suis nullement certain que chaque véhicule se comportera correctement, puisque chacun peut écrire ce qu'il veut dans l'implémentation...

Quand à celui du visiteur, comme tu dis, il ne faut pas qu'il y ait trop de responsabilités, sinon cela devient incompréhensible..

Bref, pas d'autres idées ?... on continue les switch cases, en les matinant de quelques Strategy et Visitor pour faire intello ?...

Tu peux aussi parfois remplacer le switch par une structure telle que celle-ci :

Code:

---

1 2 3 4 5

for(AbstractObject object : objects){ if(object.test(a)){ objet.doSomething(); } }

---

Par contre, ça oblige à voir une classe abstraite ou une interface et souvent de nombreux sous types. J'utilise régulièrement cette structure, mais c'est vrai que c'est parfois un peu lourd de créer une nouvelle arborescence de classes juste pour un switch, alors j'en laisse tout de même quelques-uns.