Comment coder un enum via une classe « normale »

Samuel Devulder a écrit :

Mais quand tu écris switch (monEnum)
{
case c1 : ...
case c2 : ...
other : ...
}
que fais-tu, sinon définir un traitement sur ton enum ?
et tu ne va pas, pour un enum donné, définir des centaines de
traitement (de switch donc) différents sinon c'est qu'il y a un vrai
problème de conception...

Je m'inscrit en faux! [...]

J'ai bien lu tous les messages et tout cela est vraiment intéressant.

Je me dis finalement ceci : un enum+switch, ça peut-être opportun s'il
est bien localisé dans une unique classe. Si on finit par le retrouver
dans plusieurs endroits, alors il faut repenser la conception et aller
du côté du polymorphisme. Ça vous semble correct ?



--
François Lafont

Francois a écrit :

J'ai bien lu tous les messages et tout cela est vraiment intéressant.

Je me dis finalement ceci : un enum+switch, ça peut-être opportun s'il
est bien localisé dans une unique classe. Si on finit par le retrouver
dans plusieurs endroits, alors il faut repenser la conception et aller
du côté du polymorphisme. Ça vous semble correct ?

Il manque une pondération dans le choix de l'approche en considérant la
nature du traitement qui doit être fait suivant la valeur de l'enum. Le
choix d'utiliser un switch ou de déporter le code dans la classe sur
laquelle on switch dépend en fait de la nature du traitement. Est-ce un
traitement qui a du sens à être rendu public ou est-ce un truc interne
qui n'a pas de sens dans le reste du monde.

En gros pas de dogmatisme (switch=evil), mais du pragmatisme et du bon sens.

Par exemple, un code ecrit comme ceci:
SomeClass o;
if(o.getEnum()==Enum.val1) {
// traitement 1
} else {
if(o.getEnum()==Enum.val2) {
// traitement 2
} else {
if(o.getEnum()==Enum.val3) {
// traitement 3
} else {
// comme cela sur 8 ou 9 valeurs
}
}
}
Est me semble-t-il plus lisible avec un
switch(o.getEnum()) {
case Enum.val1:
// traitement1
break;
case Enum.val2:
// traitement2
break
case Enum.val3:
// traitement2
break
}
Sans compter que si on a de traitement identiques pour des valeurs
d'enum le compilo pourra factoriser et re-organiser le code pour nous.

Le seul truc reprochable aux switch est le 'break;', bien que si on sait
bien l'utiliser on rend le code plus lisible:
switch(o.getEnum()) {
case Enum.val1:
// traitement 1
break;
case Enum.val2:
// traitement2
break
case Enum.val3:
// traitement 1 dupliqué
break
case Enum.val4:
// traitement 3
break
case Enum.val5:
// traitement 1 dupliqué
break
case Enum.val6:
// traitement 1 dupliqué
break
}
devenant:
switch(o.getEnum()) {
case Enum.val1:
case Enum.val3:
case Enum.val5:
case Enum.val6:
// traitement 1
break;
case Enum.val2:
// traitement2
break
}

Mais bon là encore pas de dogmatisme, du pragmatisme, de la souplesse et
du bon sens avant tout. La programmation n'est pas une religion avec des
dogmes, des penseurs qui pensent pour vous et ses bouc-émissaires tout
désignés responsables de tous les maux, mais un truc pour des individus
disposant de raison et réfléchissant par eux même.

sam (quoique.. c'est pas être un peu dogmatique que d'être
anti-dogmatique? :) ).

Adrien Grand a écrit :

Salut,

Francois a écrit :

Par "flou", je voulais dire en fait que je n'ai jamais eu l'expérience
réelle et palpable des inconvénients du switch. Mais cela vient du fait
que, étant un simple programmeur du dimanche, mes petits codes n'ont pas
un volume assez important pour rendre palpable cette vérité selon
laquelle le switch c'est pas bien en objet.

Ça n'est pas une vérité absolue. Pour certains problèmes, ça n'a juste
pas de sens d'utiliser le polymorphisme. Imagine que tu aies une classe
Conducteur et une enum FeuTricolore qui peut prendre les valeurs VERT,
ORANGE et ROUGE. Si tu souhaites associer des comportements différents à
ton conducteur selon la couleur du feu, il faut justement utiliser un
switch et pas le polymorphisme.

FeuTricolore est une classe d'un objet actif (il contient son propre
processus (en Java, FeuTricolore va créer un Thread qui aura pour but de
faire changer le feu de couleur (donc son Etat) en fonction des durées
qu'on lui aura passées lors de sa construction).

Ce que je préconise est la mise en oeuvre du "design pattern Strategy
(pour implémenter les enum), cf.
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/StrategyPattern.htm

Voir l'exemple :
http://www.augustana.ca/~mohrj/courses/2007.fall/csc220/examples/polymorphism.html

On peut utiliser aussi les enum polymorphes en Java :
http://langrsoft.com/articles/enum2.shtml mais ce n'est pas forcément
plus pratique.

Il est important que tes APIs restent logiques, et vouloir utiliser le
polymorphisme t'obligerait à ajouter des méthodes à ton feu qui prennent
un conducteur en argument. Or la classe FeuTricolore n'a pas à savoir
qu'il existe une classe Conducteur (C'est au conducteur de se préoccuper
du feu, pas le contraire). Le code qui associe la réaction du conducteur
à la couleur du feu devrait donc logiquement se trouver dans la classe
Conducteur.

On est bien d'accord que c'est la classe Conducteur qui doit se
préoccuper de l'état du feu. On utilisera donc le "design pattern"
Observer (car dans l'application, il n'y aura certainement pas que le
Conducteur dont le comportement dépendra de la couleur du feu mais aussi
les piétons, etc. et même si ce n'est pas le cas, ce design ménage les
évolutions ultérieures en supposant, qu'à terme, il y aura d'autres
observateurs du FeiTricolore). Le Conducteur observera l'état du feu et
en déduira son comportement. De même pour d'autres éventuels "acteurs"
comme les piétons.

Mais il y a juste une chose. Faire du
enum et du switch, c'est associer données et traitements, donc il faut
repenser la chose en objets via le polymorphisme. Mais alors dans ce cas
pourquoi s'embêter avec des enum. Dans ce cas, on fait des vraies
classes et on laisse tomber le enum. En fait, dans votre logique, j'ai
l'impression que les enum n'apportent rien et qu'on pourrait s'en passer
largement puisqu'on en arrive à faire finalement des vraies classes avec
l'héritage et compagnie. À la limite, dans votre logique, vous me diriez
que vous ne voulez pas entendre parler des enum, je trouverais ça plus
cohérent. Remarquez, c'est peut-être le cas d'ailleurs, puisque dans
l'exemple d'implémentation de l'enum Etat, vous n'avez justement pas
utilisé d'enum.

Il faut utiliser des enum quand tu cherches à décrire quelque chose qui
ne peut prendre qu'un nombre fini et connu de valeurs, comme l'état
physique d'un matériau (solide, liquide, gazeux), la couleur d'un feu
tricolore, ou les jours de la semaine. (Utiliser le polymorphisme pour
ce genre de chose n'a pas de sens.)

Voir les références que j'ai mentionnées.

La documentation de Sun donne des bons exemples d'utilisation des enums :
http://java.sun.com/docs/books/tutorial/java/javaOO/enum.html

La documentation de Sun illustre l'utilisation d'enum. Elle ne renseigne
pas sur leur pertinence...

Samuel Devulder a écrit :

Francois a écrit :

Vous n'êtes pas le premier à me dire cela, loin de là. J'avoue que
pour moi, ça reste floue cette histoire d'éviter les switch.

Moi aussi. Je ne comprends pas trop les puristes qui mettent de l'objet
partout, surtout où il n'en faudrait pas et produisent des systèmes:
- lents et gourmand en mémoire: les objets ont un coût non négligeable
par rapport aux types de base
- non évolutifs parce que le traitement n'est plus localisé à un endroit
facilement modifiable mais dispersé dans 36 classes intiment lié aux
choix de l'algo implémenté. Changer d'algo revient à toucher ces 36
classes, bref à faire un redesign complet (et alors que cela n'aurait pu
n'affecter qu'une seule classe: celle effectuant le traitement.

Tu raisonne par les traitements. En objet on raisonne par les
abstractions (données+traitements) en ayant toujours en tête les
principes d'abstraction, d'encapsulation et de modularité (forte
cohésion d'une abstraction, faible couplage entre abstractions afin de
préserver leur autonomie la plus large). Ceci induit, et je te prie de
bien vouloir m'en excuser, tout le contraire de ce que tu dis (un
traitement ne sera pas réparti dans 36 abstractions car cela ne
respecterait pas le principe de modularité).

Bref: les data se dispersent dans l'arbre d'agrégation et c'est très
bien car elles sont utiles à beaucoup, mais faire la même chose
systématiquement pour le traitement peut être mauvais si la granularité
n'est pas bonne. Ainsi choisir de faire une méthode par switch est un
mauvais choix à mon avis.

Si la méthode en question est utilisée par beaucoup d'objets, c'est
justement ce qu'il faut faire sinon on duplique beaucoup de code !

Un truc simple pour savoir si le découpage est le bon est de regarder si
les méthodes-switch ne sont appelées que depuis un seul point (ce qui
est assez logique vu qu'elles effectue un traitement qui aurait du être
fait par une autre classe). Si c'est le cas, il faudrait voir si le
traitement n'est pas trop spécifique au point d'appel et ne devrait pas
être publié par la classe-enum mais plutôt déplacé à l'endroit où on en
a besoin.

Tu prends le problème à l'envers car on ne part pas du code mais de la
conception !
C'est donc en conception qu'on se pose la question de comment
implémenter un enum. Je répète que c'est une abstraction comme une
autre. Donc il faut se poser les questions :
- Est-elle très réutilisée par différentes abstractions ? si oui,
utiliser le pattern Strategy pour implémenter l'enum (donc utiliser mon
point de vue)
- Doit-elle posséder des traitements généraux utiles à tous le monde ?
si oui, implémenter l'enum comme une classe.
- Au contraire est-elle très localisée ? si oui, on peut, peut-être,
utiliser un enum simple et un switch

je rappelle que :
1) les enum polymorphes existent en Java.
Voir : http://langrsoft.com/articles/enum2.shtml
2) Toujours en Java, on peut ajouter des méthodes (polymorphes) aux
enums. Ceci devrait poser questions à ceux qui préconisent des switch...

Wykaaa a écrit :

Tu raisonne par les traitements. En objet on raisonne par les

Ce sont les traitements sur les data qui font le travail et apportent de
la valeur à un soft je pense bien. Il est important que le traitement
soit bien placé dans les choix architecturaux, car si on raisonne sans
se préoccuper des traitements, on a un joli diagramme de classe plein de
joli design patterns mais impraticable par la suite pour ceux qui
doivent tirer parti des data pour faire des traitements efficaces.

> <snip>

Bref: les data se dispersent dans l'arbre d'agrégation et c'est très
bien car elles sont utiles à beaucoup, mais faire la même chose
systématiquement pour le traitement peut être mauvais si la
granularité n'est pas bonne. Ainsi choisir de faire une méthode par
switch est un mauvais choix à mon avis.

Si la méthode en question est utilisée par beaucoup d'objets, c'est
justement ce qu'il faut faire sinon on duplique beaucoup de code !

Ce que je dis c'est que si dans la classe enum les méthodes ne sont
utilisées que par une seule autre classe, c'est qu'alors il y a lieu de
se poser la question de savoir si cette méthode ne devrait pas plutôt
figurer dans la classe qui en a besoin (localiser les traitements).

Un truc simple pour savoir si le découpage est le bon est de regarder
si les méthodes-switch ne sont appelées que depuis un seul point (ce
qui est assez logique vu qu'elles effectue un traitement qui aurait du
être fait par une autre classe). Si c'est le cas, il faudrait voir si
le traitement n'est pas trop spécifique au point d'appel et ne devrait
pas être publié par la classe-enum mais plutôt déplacé à l'endroit où
on en a besoin.

Tu prends le problème à l'envers car on ne part pas du code mais de la
conception !

Quand le code est là (99% des programmes finalement), ou que tu n'es pas
la personne en charge de la conception et ce qu'on te demande c'est de
travailler avec l'existant sans rien casser (la vie de tous les jours
quoi), et bien finalement tu es assez content de pouvoir utiliser l'enum
localement dans un switch plutôt que d'avoir à ajouter une méthode dans
la classe Enum parce que soit tu n'en a pas le droit (politique de
responsabilité: tu sors de ton périmètre), soit tu ne peux pas (pas de
code fourni).

C'est donc en conception qu'on se pose la question de comment
implémenter un enum. Je répète que c'est une abstraction comme une
autre. Donc il faut se poser les questions :
- Est-elle très réutilisée par différentes abstractions ? si oui,
utiliser le pattern Strategy pour implémenter l'enum (donc utiliser mon
point de vue)
- Doit-elle posséder des traitements généraux utiles à tous le monde ?
si oui, implémenter l'enum comme une classe.
- Au contraire est-elle très localisée ? si oui, on peut, peut-être,
utiliser un enum simple et un switch

je rappelle que :
1) les enum polymorphes existent en Java.
Voir : http://langrsoft.com/articles/enum2.shtml
2) Toujours en Java, on peut ajouter des méthodes (polymorphes) aux
enums. Ceci devrait poser questions à ceux qui préconisent des switch...

Pas n'importe quelles méthodes non plus. Tu ne peux pas avoir "d'état"
dans ton enum. Si ton code a besoin d'états, il te faut une classe! En
pratique ce sont des méthodes simple sans effets de bords. Elle
retournent la constante représentant l'enum dans un autre format ou
effectuent des tests (cas exposé dans l'url).

En tout état de cause, je vois que tu te place au niveau conception, et
moi au niveau pratique. Au niveau conception je suis d'accord on peut se
poser la question d'avoir des enum ou des objets en nombres "finis".

Mais une fois ce choix effectué, tu dois faire avec l'existant et
finalement tu utilises les switchs parce que c'est plus pratique qu'un
nombre incessant de if/else/if imbriqué.

Bref, il est des cas où l'enum n'est finalement qu'une valeur
symbolique, et dans ce cas il faut le traiter comme on traite les
constantes entières et donc ils ont toute leur place dans les switch()s.
Tu trouvera quand même qu'il vaut mieux utiliser un Enum qu'une
constante entière dans le code, non ?

A l'inverse il est des cas ou l'on trouve un enum dans les attributs
d'une classe et que beaucoup de méthodes de la classe dépendent de la
valeur de l'enum pour effectuer un traitement différent (en gros l'enum
sert à encoder des sous-classes qui n'ont pas été définies) et là je
suis d'accord qu'il vaut mieux dégager l'attribut Enum et ajouter des
sous-classes pour particulariser les traitements.

Tout dépend de ce qu'on veut faire de l'Enum finalement.

sam.

Re,

Ah ça a l'air cool, pleins de design patterns. Mais on ne sait toujours
pas comment tu stockes l'état du feu si ce n'est une enum.

Voir les références que j'ai mentionnées.

La documentation de Sun donne des bons exemples d'utilisation des enums :
http://java.sun.com/docs/books/tutorial/java/javaOO/enum.html

La documentation de Sun illustre l'utilisation d'enum. Elle ne renseigne
pas sur leur pertinence...

C'est implicite. Tu ferais une interface JourDeLaSemaine avec une
implémentation par jour pour décrire les jours de la semaine ? Non. Donc
c'est typiquement un cas pour lequel l'utilisation des enums est pertinent.

--
jpountz

Adrien Grand a écrit :

Re,

Ah ça a l'air cool, pleins de design patterns. Mais on ne sait toujours
pas comment tu stockes l'état du feu si ce n'est une enum.

C'est très simple, il n'est pas stocké, puisque ce sont les sous-classes
qui donnent la couleur et quand on a besoin de la couleur du feu, on
teste par instanceof.

Voir les références que j'ai mentionnées.

La documentation de Sun donne des bons exemples d'utilisation des enums :
http://java.sun.com/docs/books/tutorial/java/javaOO/enum.html

La documentation de Sun illustre l'utilisation d'enum. Elle ne renseigne
pas sur leur pertinence...

C'est implicite. Tu ferais une interface JourDeLaSemaine avec une
implémentation par jour pour décrire les jours de la semaine ? Non. Donc
c'est typiquement un cas pour lequel l'utilisation des enums est pertinent.

Et bien je l'ai fait et ça me paraît la façon la plus naturelle car pour
chaque jour de la semaine, il n'y a pas forcément les mêmes activités et
j'utiliserai donc le polymorphisme sur les sous-classes représentant
chaque jour de la semaine pour déclencher des activités (j'aurai une
méthode activerLesActivites() qui déclenchera, suivant le jour
considéré, des activités différentes).

Samuel Devulder a écrit :

Wykaaa a écrit :

Tu raisonne par les traitements. En objet on raisonne par les

Ce sont les traitements sur les data qui font le travail et apportent de
la valeur à un soft je pense bien. Il est important que le traitement
soit bien placé dans les choix architecturaux, car si on raisonne sans
se préoccuper des traitements, on a un joli diagramme de classe plein de
joli design patterns mais impraticable par la suite pour ceux qui
doivent tirer parti des data pour faire des traitements efficaces.

Mais en objet, quand on fait une conception, on se pose la question
première : quelles abstractions me sont utiles ?
Ensuite, les traitements se placent naturellement selon les principes de
modularité (forte cohérence d'une abstraction : toutes les traitements
liés à l'abstraction sont définis dans CETTE abstraction, et faible
couplage : on réduit les dépendances entre abstractions en utilisant
l'encapsulation).

> <snip>

Bref: les data se dispersent dans l'arbre d'agrégation et c'est très
bien car elles sont utiles à beaucoup, mais faire la même chose
systématiquement pour le traitement peut être mauvais si la
granularité n'est pas bonne. Ainsi choisir de faire une méthode par
switch est un mauvais choix à mon avis.

Si la méthode en question est utilisée par beaucoup d'objets, c'est
justement ce qu'il faut faire sinon on duplique beaucoup de code !

Ce que je dis c'est que si dans la classe enum les méthodes ne sont
utilisées que par une seule autre classe, c'est qu'alors il y a lieu de
se poser la question de savoir si cette méthode ne devrait pas plutôt
figurer dans la classe qui en a besoin (localiser les traitements).

Ca dépend si l'abstraction qui représente l'enum est importante ou non
pour l'application.

Un truc simple pour savoir si le découpage est le bon est de regarder
si les méthodes-switch ne sont appelées que depuis un seul point (ce
qui est assez logique vu qu'elles effectue un traitement qui aurait
du être fait par une autre classe). Si c'est le cas, il faudrait voir
si le traitement n'est pas trop spécifique au point d'appel et ne
devrait pas être publié par la classe-enum mais plutôt déplacé à
l'endroit où on en a besoin.

Tu prends le problème à l'envers car on ne part pas du code mais de la
conception !

Quand le code est là (99% des programmes finalement), ou que tu n'es pas
la personne en charge de la conception et ce qu'on te demande c'est de
travailler avec l'existant sans rien casser (la vie de tous les jours
quoi), et bien finalement tu es assez content de pouvoir utiliser l'enum
localement dans un switch plutôt que d'avoir à ajouter une méthode dans
la classe Enum parce que soit tu n'en a pas le droit (politique de
responsabilité: tu sors de ton périmètre), soit tu ne peux pas (pas de
code fourni).

Je ne parlais pas de refactorer du code existant. Dans ce cas, il existe
des règles mais si on est très éloigné de ce que je préconise dans le
code existant, on fera autrement (et plutôt comme on peut).

C'est donc en conception qu'on se pose la question de comment
implémenter un enum. Je répète que c'est une abstraction comme une
autre. Donc il faut se poser les questions :
- Est-elle très réutilisée par différentes abstractions ? si oui,
utiliser le pattern Strategy pour implémenter l'enum (donc utiliser
mon point de vue)
- Doit-elle posséder des traitements généraux utiles à tous le monde ?
si oui, implémenter l'enum comme une classe.
- Au contraire est-elle très localisée ? si oui, on peut, peut-être,
utiliser un enum simple et un switch

je rappelle que :
1) les enum polymorphes existent en Java.
Voir : http://langrsoft.com/articles/enum2.shtml
2) Toujours en Java, on peut ajouter des méthodes (polymorphes) aux
enums. Ceci devrait poser questions à ceux qui préconisent des switch...

Pas n'importe quelles méthodes non plus. Tu ne peux pas avoir "d'état"
dans ton enum. Si ton code a besoin d'états, il te faut une classe! En
pratique ce sont des méthodes simple sans effets de bords. Elle
retournent la constante représentant l'enum dans un autre format ou
effectuent des tests (cas exposé dans l'url).

C'est pour ça que j'ai pris des précautions sur l'emploi des enum
polymorphes car ce n'est pas toujours pratique si on veut des méthodes
sophistiquées.

En tout état de cause, je vois que tu te place au niveau conception, et
moi au niveau pratique. Au niveau conception je suis d'accord on peut se
poser la question d'avoir des enum ou des objets en nombres "finis".

Alors on est d'accord :-)

Mais une fois ce choix effectué, tu dois faire avec l'existant et
finalement tu utilises les switchs parce que c'est plus pratique qu'un
nombre incessant de if/else/if imbriqué.

Oui mais moi je n'ai ni switch ni if imbriqués dans certains cas. Tout
est résolu par le polymorphisme qui me sert d'aiguillage (éventuellement
en cascade).

Bref, il est des cas où l'enum n'est finalement qu'une valeur
symbolique, et dans ce cas il faut le traiter comme on traite les
constantes entières et donc ils ont toute leur place dans les switch()s.
Tu trouvera quand même qu'il vaut mieux utiliser un Enum qu'une
constante entière dans le code, non ?

Ah oui. Jamais de valeurs littérales dans le code (sauf 0 ou 1 quand
c'est pertinent)

A l'inverse il est des cas ou l'on trouve un enum dans les attributs
d'une classe et que beaucoup de méthodes de la classe dépendent de la
valeur de l'enum pour effectuer un traitement différent (en gros l'enum
sert à encoder des sous-classes qui n'ont pas été définies) et là je
suis d'accord qu'il vaut mieux dégager l'attribut Enum et ajouter des
sous-classes pour particulariser les traitements.

On est toujours d'accord ;-)

Tout dépend de ce qu'on veut faire de l'Enum finalement.

sam.

Si on fait une nouvelle application (pas de reprise de code existant),
c'est quelque chose qui se décide en conception.

Wykaaa a écrit :

C'est implicite. Tu ferais une interface JourDeLaSemaine avec une
implémentation par jour pour décrire les jours de la semaine ? Non. Donc
c'est typiquement un cas pour lequel l'utilisation des enums est
pertinent.

Et bien je l'ai fait et ça me paraît la façon la plus naturelle car pour
chaque jour de la semaine, il n'y a pas forcément les mêmes activités et
j'utiliserai donc le polymorphisme sur les sous-classes représentant
chaque jour de la semaine pour déclencher des activités (j'aurai une
méthode activerLesActivites() qui déclenchera, suivant le jour
considéré, des activités différentes).

Je crois que le problème est que les points de vue ne sont pas les
mêmes. Wykaaa se place d'un point de vue conception et nous autres nous
plaçons peut-être plus d'un point de vue implémentation.

Du point de vue conception, Wykaaa veut faire des enum de vraies classes
avec de l'héritage et compagnie. C'est assez logique de ce point de vue,
que viendraient faire des enum "basiques" dans une conception objet ? On
peut se demander alors pourquoi avoir des enum si c'est pour en faire de
"vrais" objets. Mais comme Wykaaa au final n'utilise pas enum justement,
donc c'est assez.

Du point de vue implémentation, on considère les enum comme un type
simple (c'est un moyen pour simuler [via les classes] un type simple
avec un nombre finis de valeurs auto-documentées). Au même titre que
dans l'implémentation on a souvent besoin des entiers et bien on peut
avoir aussi besoin d'enum (qui prennent un nombre finis de valeurs) qui
peuvent se montrer plus adaptés que les entiers. Je pense que dans
l'implémentation d'une classe, Wykaaa ne verrait pas d'inconvénient à
voir un enum ici ou là, non ? :-)

Pour l'exemple des feux tricolores, je les verrais bien comme des objets
dont l'état serait bien représenté par un type enum (Couleur). Mais
pour les jours de la semaine, j'avoue que j'ai du mal à trouver naturel
qu'ils soient vue comme de "vrais objets" (dans le sens "plus étoffés
que des enum basiques").



--
François Lafont

> Par exemple, un code ecrit comme ceci:
SomeClass o;
if(o.getEnum()==Enum.val1) {
// traitement 1
} else {
if(o.getEnum()==Enum.val2) {
// traitement 2
} else {
if(o.getEnum()==Enum.val3) {
// traitement 3
} else {
// comme cela sur 8 ou 9 valeurs
}
}
}
Est me semble-t-il plus lisible avec un
switch(o.getEnum()) {
case Enum.val1:
// traitement1
break;
case Enum.val2:
// traitement2
break
case Enum.val3:
// traitement2
break
}
Sans compter que si on a de traitement identiques pour des valeurs
d'enum le compilo pourra factoriser et re-organiser le code pour nous.

Oui, mais c'est un peu biaisé comme comparaison de lisibilité :) .
On peut aussi écrire les if / else if comme ça :

if(o.getEnum()==Enum.val1) {
// traitement 1
} else if(o.getEnum()==Enum.val2) {
// traitement 2
} else if(o.getEnum()==Enum.val3) {
// traitement 3
} else {
// comme cela sur 8 ou 9 valeurs
}