Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Comment coder un enum via une classe « normale »

59 réponses
Avatar
Francois
Bonjour à tous,

Ma question n'a pas un grand intérêt pratique, c'est juste pour
comprendre les enum. En fait, je comprends bien l'utilité des enum et la
façon dont on s'en sert. Mais, si j'ai bien compris, le mot clé "enum" a
été créé dans la version 1.5 de Java pour avoir un type énuméré en deux
coup de cuillère à pot, sachant qu'avant la version 1.5 il fallait coder
soi-même sa propre classe donnant le type énuméré souhaité.

Justement, on codait comment en version 1.4 (ou antérieure) ? Par
exemple, comment avec une classe « normale » peut-on coder un équivalent
de cet exemple très simple de type enum :

public enum Etat {
DEHORS,
DEDANS
}

Merci d'avance.

--
François Lafont

10 réponses

1 2 3 4 5
Avatar
Francois
En y réfléchissant, je pense pouvoir préciser ma question.

Si l'on passe sur toutes les méthodes que doivent probablement posséder
les types enum (et que j'ignore d'ailleurs), est-ce qu'on peut dire
qu'écrire ce code :

//---------------------------
public enum Etat {
DEHORS,
DEDANS
}
//---------------------------

revient globalement à écrire ce code ?

//---------------------------
public class Etat {
public static final Etat DEDANS = new Etat();
public static final Etat DEHORS = new Etat();
private Etat() {}
}
//---------------------------



--
François Lafont
Avatar
Adrien Grand
Bonsoir,

Francois a écrit :
En y réfléchissant, je pense pouvoir préciser ma question.

Si l'on passe sur toutes les méthodes que doivent probablement posséder
les types enum (et que j'ignore d'ailleurs), est-ce qu'on peut dire
qu'écrire ce code :

//---------------------------
public enum Etat {
DEHORS,
DEDANS
}
//---------------------------

revient globalement à écrire ce code ?

//---------------------------
public class Etat {
public static final Etat DEDANS = new Etat();
public static final Etat DEHORS = new Etat();
private Etat() {}
}
//---------------------------



Ça y ressemble en tout cas. :-) Ceci dit, quand j'écris des enums en
Java 5+, j'ai souvent tendance à les utiliser dans des switch/case, ce
qui n'est pas possible en utilisant des objets.

Dans ce cas précis, je pense que j'aurais plutôt eu tendance à écrire
quelque chose comme :

//--------------------------
public class Constants {
public static final ETAT_DEHORS = 0;
public static final ETAT_DEHORS = 1;
}
//--------------------------

L'avantage d'utiliser des /int/ plutôt que des objets est que tu peux
les utiliser dans un switch/case et qu'ils sont plus simples à manipuler
(== au lieu de equals(), etc.).

--
jpountz
Avatar
Francois
Adrien Grand a écrit :

Ça y ressemble en tout cas. :-)



Ah, voilà qui me rassure.

Ceci dit, quand j'écris des enums en
Java 5+, j'ai souvent tendance à les utiliser dans des switch/case, ce
qui n'est pas possible en utilisant des objets.

Dans ce cas précis, je pense que j'aurais plutôt eu tendance à écrire
quelque chose comme :

//--------------------------
public class Constants {
public static final ETAT_DEHORS = 0;
public static final ETAT_DEHORS = 1;
}
//--------------------------

L'avantage d'utiliser des /int/ plutôt que des objets est que tu peux
les utiliser dans un switch/case et qu'ils sont plus simples à manipuler
(== au lieu de equals(), etc.).



Mais dans les "switch/case", on a le droit de mettre des enum justement,
non ? En tout cas, chez moi, ceci compile sans problème :

//---------------------------
enum Etat {DEHORS, DEDANS}

class Main {

public static void main(String[] args) {

Etat etat = Etat.DEHORS;

switch(etat) {
case DEDANS:
System.out.println("Je suis dehors");
break;
case DEHORS:
System.out.println("Je suis dedans");
break;
}
}
}
//---------------------------

Donc au contraire, les enum (qui sont des objets si j'ai bien compris)
sont justement tout indiqués pour les "switch/case", non ? Ça me semble
être en contradiction avec ta remarque.


--
François Lafont
Avatar
Wykaaa
Francois a écrit :
Bonjour à tous,

Ma question n'a pas un grand intérêt pratique, c'est juste pour
comprendre les enum. En fait, je comprends bien l'utilité des enum et la
façon dont on s'en sert. Mais, si j'ai bien compris, le mot clé "enum" a
été créé dans la version 1.5 de Java pour avoir un type énuméré en deux
coup de cuillère à pot, sachant qu'avant la version 1.5 il fallait coder
soi-même sa propre classe donnant le type énuméré souhaité.

Justement, on codait comment en version 1.4 (ou antérieure) ? Par
exemple, comment avec une classe « normale » peut-on coder un équivalent
de cet exemple très simple de type enum :

public enum Etat {
DEHORS,
DEDANS
}

Merci d'avance.



J'implémente les enum en Java, de la façon suivante car je n'aime pas
les "switch" :

public abstract class Etat
{
Etat() { }
traitementEtat () { }
}

classe EtatDehors extends Etat
{
EtatDehors () { }
traitementEtat ()
{
// traitement de EtatDehors
}
}

classe EtatDedans extends Etat
{
EtatDedans () { }
traitementEtat ()
{
// traitement de EtatDedans
}
}

//Utilisation :
Etat monEtat1 = new EtatDehors ();
Etat monEtat2 = new EtatDedans ();

monEtat1.traitementEtat(); // laissons faire le polymorphisme
monEtat2.traitementEtat(); // " " " "

Ceci évite les "switch" qui sont inélégants et inesthétiques et qui
obligent à modifier et le switch et la classe quand on ajoute des valeurs.
Avec mon implémentation, pour ajouter une valeur à l'enum, il suffit
d'ajouter une nouvelle sous-classe à Etat et de coder le traitement "qui
va bien".
Avantages : on ne touche pas le code existant (donc pas besoin de tests
de non régression). On ne teste que la ou les nouvelles valeurs ajoutées.

Rappelez-vous ceci :
La chasse au switch est à la programmation objet ce que la chasse au
goto est à la programmation structurée !

Il n'y a jamais besoin de switch en programmation objet si on utilise un
langage objet correctement, c'est-à-dire en utilisant le polymorphisme.

En fait, on peut même, ici, dans ce cas très simple, utiliser une
interface au lieu d'une classe abstraite.
Avatar
Samuel Devulder
Wykaaa a écrit :
Ceci évite les "switch" qui sont inélégants et inesthétiques et qui
obligent à modifier et le switch et la classe quand on ajoute des valeurs.
Avec mon implémentation, pour ajouter une valeur à l'enum, il suffit
d'ajouter une nouvelle sous-classe à Etat et de coder le traitement "qui
va bien".



Je ne suis pas d'accord. Tu va devoir modifier tes classes pour ajouter
systématiquement des nouvelles méthodes pour chaque nouveau switch que
tu voudra éliminer dans un autre classe utilisant ton enum. Je trouve
cela particulièrement inélégant. Imagines le nombre de méthodes que ton
enum va porter au final. Cette technique est irrealiste pour un code à
effectuant plusieurs centaines de traitements différents basés sur la
valeur de l'enum.

Le code d'un enum codé ainsi n'a pas à contenir des traitements devant
être effectués par un autre objet: l'enum est défini indépendamment de
ce qu'on va faire de lui. Il faut concevoir l'enum non pas comme un
objet structuré mais plutôt comme un ensemble de valeurs finies que l'on
peut assimiler aux types de bases et donc utilisable dans un switch (le
compilo peut faire de la vérif dessus).

Enfin ton approche bloque quand l'enum ainsi codé n'est pas dispo sous
la forme d'un code source. Tu nous dit de sous-classe, mais cela ne
marche pas car le reste du code livré lui aussi sous la forme de .class
n'utilisera pas ton extension et ne pourra donc pas fournir les
nouvelles méthodes que tu as ajouté à la sous-classe.

sam
Avatar
Wykaaa
Samuel Devulder a écrit :
Wykaaa a écrit :
Ceci évite les "switch" qui sont inélégants et inesthétiques et qui
obligent à modifier et le switch et la classe quand on ajoute des
valeurs.
Avec mon implémentation, pour ajouter une valeur à l'enum, il suffit
d'ajouter une nouvelle sous-classe à Etat et de coder le traitement
"qui va bien".



Je ne suis pas d'accord. Tu va devoir modifier tes classes pour ajouter
systématiquement des nouvelles méthodes pour chaque nouveau switch que
tu voudra éliminer dans un autre classe utilisant ton enum. Je trouve
cela particulièrement inélégant. Imagines le nombre de méthodes que ton
enum va porter au final. Cette technique est irrealiste pour un code à
effectuant plusieurs centaines de traitements différents basés sur la
valeur de l'enum.



Si tu as plusieurs centaines de traitements différents pour un enum, il
y a un sérieux problème de conception !!

Le code d'un enum codé ainsi n'a pas à contenir des traitements devant
être effectués par un autre objet: l'enum est défini indépendamment de
ce qu'on va faire de lui.



Ok. J'ai été un peu rapide en intégrant directement un traitement dans
l'enum. C'était juste pour montrer le principe. La construction doit
être un peu plus sophistiquée. En fait, les utilisateurs de l'enum
feront des sous-classes de Dedans et Dehors s'ils veulent des
traitements spécifiques. Ceci garantit la compatibilité ascendante car
si on ajoute des sous-classes à Etat, les utilisateurs ne sont pas
obligés de modifier leur code immédiatement (s'ils n'ont pas de
traitement spécifique à faire pour les nouvelles valeurs).

Il faut concevoir l'enum non pas comme un
objet structuré mais plutôt comme un ensemble de valeurs finies que l'on
peut assimiler aux types de bases et donc utilisable dans un switch (le
compilo peut faire de la vérif dessus).



Là je suis en total désaccord avec toi.

Enfin ton approche bloque quand l'enum ainsi codé n'est pas dispo sous
la forme d'un code source. Tu nous dit de sous-classe, mais cela ne
marche pas car le reste du code livré lui aussi sous la forme de .class
n'utilisera pas ton extension et ne pourra donc pas fournir les
nouvelles méthodes que tu as ajouté à la sous-classe.



Ceci est un faux problème car les nouvelles sous-classes peuvent être
livrées dans un nouveau .class. Heureusement que je ne suis pas obligé
de mettre toutes les sous-classes d'une classe dans un même .class

De toute façon, les utilisateurs ne verrons que la classe abstraite (ou
mieux l'interface). Le reste c'est le polymorphisme qui le résoudra.
Avatar
Samuel Devulder
Wykaaa a écrit :

Si tu as plusieurs centaines de traitements différents pour un enum, il
y a un sérieux problème de conception !!



Je ne pense pas non. Utiliser la valeur du code d'un enum à plusieurs
endroit me semble très naturel dans plein de langages. C'est comme
utiliser des entiers, mais dont les valeurs numériques nous sont
masquées. La seule chose qu'on peut faire dessus c'est même pas de les
comparer, mais uniquement tester l'égalité (operateur ==).

Vouloir tout centraliser sur l'enum c'est confondre le rôle d'un enum et
d'une classe. Un enum c'est conceptuellement comme un ensemble de
valeurs finies. Cela n'a pas plus d'intérêt en soit qu'un objet n'ayant
que des accesseurs de type getXXXX(). Irait-on redefinir la classe
Integer en ajoutant un nouveau traitement à chaque fois qu'on a un
switch dans du code?

Faire faire autre chose à un enum que retourner des valeurs, en
particulier lui faire faire un traitement sur des données passées en
argument ne me semble pas propre car cela devrait être réservé aux vrais
objets dont les méthodes "font" quelque chose là ou les énums
"retournent" une valeur invariable, une constante finalement.

Ok. J'ai été un peu rapide en intégrant directement un traitement dans
l'enum. C'était juste pour montrer le principe. La construction doit
être un peu plus sophistiquée. En fait, les utilisateurs de l'enum
feront des sous-classes de Dedans et Dehors s'ils veulent des
traitements spécifiques. Ceci garantit la compatibilité ascendante car
si on ajoute des sous-classes à Etat, les utilisateurs ne sont pas
obligés de modifier leur code immédiatement (s'ils n'ont pas de
traitement spécifique à faire pour les nouvelles valeurs).



Ce que tu décris là est un objet, pas un enum. Un enum est comme un
nombre. On ne lui demande pas de calculer, mais juste de pouvoir être
évalué et nous retourner une valeur.

Il faut concevoir l'enum non pas comme un objet structuré mais plutôt
comme un ensemble de valeurs finies que l'on peut assimiler aux types
de bases et donc utilisable dans un switch (le compilo peut faire de
la vérif dessus).



Là je suis en total désaccord avec toi.



C'est probablement parce que l'enum est un objet pour toi.

Ceci est un faux problème car les nouvelles sous-classes peuvent être
livrées dans un nouveau .class. Heureusement que je ne suis pas obligé
de mettre toutes les sous-classes d'une classe dans un même .class



Les objets antérieur retournant la sur-classe n'auront pas les méthodes
ajoutés par la sous-classe, et donc ne pourront être traités dans les
objets où les switchs et les tests ont étés remplacés par des appels
délégués aux valeurs d'enum. (oula c'est pas facile à lire!)

De toute façon, les utilisateurs ne verrons que la classe abstraite (ou
mieux l'interface). Le reste c'est le polymorphisme qui le résoudra.



Si tu ajoute des traitements, tu devra les définir dans la classe
abstraite, mais cette dernière ne peut plus être enrichie. Elle existe
telle que définie dans le fichier class. En java contrairement à
d'autres langages comme smalltalk on ne peut enrichir une classe "par le
haut" (sauf à faire des bricolages pointus à base de classloader qui
dépassent de loin le sujet du fil de discussion).

sam :)
Avatar
Francois
Wykaaa a écrit :

J'implémente les enum en Java, de la façon suivante car je n'aime pas
les "switch" : [...]



Ce n'était pas le sens de ma question initiale car ma question initiale
était plutôt : "si on devait implémenter fidèlement un enum basique
comme Etat en Java version 1.4 (ou moins), il faudrait écrire quoi ?".
Mais en fait, à moins que j'ai dit une grosse bêtise dans le message 2
du fil, je pense que cette question est plus ou moins réglée.

Du coup, votre discussion sur des problèmes de "conception" (je ne sais
pas si c'est le bon terme) m'intéresse beaucoup. Alors, allons y... :-)

Rappelez-vous ceci :
La chasse au switch est à la programmation objet ce que la chasse au
goto est à la programmation structurée !

Il n'y a jamais besoin de switch en programmation objet si on utilise un
langage objet correctement, c'est-à-dire en utilisant le polymorphisme.



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.

Après, sur la question des enum, leur associer des traitements n'est-il
pas aller au delà de la fonction initiale des enum ? J'ai un peu lu la
suite de la discussion et je suis un peu d'accord (je n'affirme rien
bien sûr) avec ce que disait Samuel sur le point suivant : les enum sont
un moyen sûr de disposer d'un type prenant un ensemble fini de valeurs
auto-documentées et c'est à peu près tout. Si l'on veut associer des
traitements à ces valeurs, alors il me semble qu'il faudrait plutôt
s'orienter vers des classes en bonnes et dues formes. Mais je peux me
tromper. :-)



--
François Lafont
Avatar
Wykaaa
Samuel Devulder a écrit :
Wykaaa a écrit :

Si tu as plusieurs centaines de traitements différents pour un enum,
il y a un sérieux problème de conception !!



Je ne pense pas non. Utiliser la valeur du code d'un enum à plusieurs
endroit me semble très naturel dans plein de langages. C'est comme
utiliser des entiers, mais dont les valeurs numériques nous sont
masquées. La seule chose qu'on peut faire dessus c'est même pas de les
comparer, mais uniquement tester l'égalité (operateur ==).

Vouloir tout centraliser sur l'enum c'est confondre le rôle d'un enum et
d'une classe. Un enum c'est conceptuellement comme un ensemble de
valeurs finies. Cela n'a pas plus d'intérêt en soit qu'un objet n'ayant
que des accesseurs de type getXXXX(). Irait-on redefinir la classe
Integer en ajoutant un nouveau traitement à chaque fois qu'on a un
switch dans du code?



Mais un enum sert à une seule chose dans une conception !
prenons l'exemple d'un outil de dessin genre Draw. Je ne vais pas faire
un enum Figure {RECTANGLE, ELLIPSE, CERCLE, etc.} avec des switch à n'en
plus finir partout.
Non, je vais faire une interface Figure avec les fonctions qui vont bien
(calculerPerimetre, calculerSurface, remplirCouleur, etc.). Je sais
quelles sont les fonctions que je veux appliquer à mon enum. C'est un
type comme un autre : il a un ensemble de valeurs et des opérations
associées (c'est ça la définition d'un type).
Ensuite, je vais implémenter cette interface figure autant de fois que
j'ai de types différents de figures.

Remarque : dans un logiciel rigoureusement construit, on ne devrait
jamais manipuler les types de base directement. J'ai connu plusieurs
projets où c'était interdit !

Faire faire autre chose à un enum que retourner des valeurs, en
particulier lui faire faire un traitement sur des données passées en
argument ne me semble pas propre car cela devrait être réservé aux vrais
objets dont les méthodes "font" quelque chose là ou les énums
"retournent" une valeur invariable, une constante finalement.



Je ne passe pas de données aux traitements associés aux sous-classes
représentant mes différentes valeurs, parce que je SAIS quel traitement
appliquer pour calculer la surface d'un cercle ou d'un rectangle quand
je suis dans sa classe !

Ok. J'ai été un peu rapide en intégrant directement un traitement dans
l'enum. C'était juste pour montrer le principe. La construction doit
être un peu plus sophistiquée. En fait, les utilisateurs de l'enum
feront des sous-classes de Dedans et Dehors s'ils veulent des
traitements spécifiques. Ceci garantit la compatibilité ascendante car
si on ajoute des sous-classes à Etat, les utilisateurs ne sont pas
obligés de modifier leur code immédiatement (s'ils n'ont pas de
traitement spécifique à faire pour les nouvelles valeurs).



Ce que tu décris là est un objet, pas un enum. Un enum est comme un
nombre. On ne lui demande pas de calculer, mais juste de pouvoir être
évalué et nous retourner une valeur.

Il faut concevoir l'enum non pas comme un objet structuré mais plutôt
comme un ensemble de valeurs finies que l'on peut assimiler aux types
de bases et donc utilisable dans un switch (le compilo peut faire de
la vérif dessus).



Là je suis en total désaccord avec toi.



C'est probablement parce que l'enum est un objet pour toi.



Oui, c'est ce que j'ai essayé de décrire plus précisément que dans mes
posts précédents ci-dessus.
De toute façon quand tu fais un switch sur un enum, c'est bien pour
définir un traitement. Tu ne vas pas en définir des centaines pour un enum.
Le désavantage des enum c'est justement que le code est dilué partout...

C'est Bertrand Meyer (auteur du langage Eiffel) qui disait : si vous
avez trop de code, mettez-le dans les données. C'est ce que je fais en
éliminant les switch : je remplace chaque valeur par une sous-classe
d'une classe abstraite ou interface qui représente l'abstraction que
représente l'enum.
Coder avec des switch dans un langage objet c'est conserver les réflexes
du bon vieux langage C (ou Pascal, Ada avec case...of, ou PL/1 avec
select, ou Cobol avec evaluate).

Ceci est un faux problème car les nouvelles sous-classes peuvent être
livrées dans un nouveau .class. Heureusement que je ne suis pas obligé
de mettre toutes les sous-classes d'une classe dans un même .class



Les objets antérieur retournant la sur-classe n'auront pas les méthodes
ajoutés par la sous-classe, et donc ne pourront être traités dans les
objets où les switchs et les tests ont étés remplacés par des appels
délégués aux valeurs d'enum. (oula c'est pas facile à lire!).



Ils ne peuvent pas retourner un objet de la sur-classe puisque soit elle
est abstraite, soit c'est une interface.
Justement, je n'ai rien à changer dans dans le code qui fait des appels
délégués aux traitement de l'enum puisque c'est le polymorphisme qui
agit. Pour reprendre mon exemple des figures, si j'ajoute la sous-classe
hexagone, mon code maFigure.calculerSurface() me rendra la surface de
l'hexagone que j'aurai affecté à maFigure de type Figure.
Ca t'évite d'aller bidouiller tous les "case" associés à la foultitude
de switch sur ton enum qui ont été codés par d'autres, dans d'autres
modules dont tu n'as même pas connaissance (dans un grand projet comme
ceux auxquels je me suis frotté).

De toute façon, les utilisateurs ne verrons que la classe abstraite
(ou mieux l'interface). Le reste c'est le polymorphisme qui le résoudra.



Si tu ajoute des traitements, tu devra les définir dans la classe
abstraite, mais cette dernière ne peut plus être enrichie.



Si c'est une interface, je peux l'enrichir en faisant une sous-interface
qui en hérite. De même avec une classe abstraite.

Elle existe
telle que définie dans le fichier class. En java contrairement à
d'autres langages comme smalltalk on ne peut enrichir une classe "par le
haut" (sauf à faire des bricolages pointus à base de classloader qui
dépassent de loin le sujet du fil de discussion).

sam :)



Non je ne souhaite pas m'embarquer dans le classLoader ;-) mais on peut
l'enrichir par le bas.

J'ai fait ça de nombreuses fois dans des projets C++ et Java qui
faisaient plusieurs millions de lignes (entre 2 et 4,5 millions) dans le
domaine des systèmes de commandement militaire. Ca fonctionne très bien
et comme il y a des évolutions constantes et que ces logiciels ont une
très longue dure de vie, c'est ce qui permet de les rendre très
évolutifs sans toucher tout le code dès qu'on ajoute de nouveaux cas
(des nouvelles valeurs d'enum). Evidemment, ceci n'est vrai que si les
principes d'abstraction et d'encapsulation sont rigoureusement respectés...
Reprise de l'exemple figure :
Si maintenant, tu veux ajouter un traitement spécifique à une figure
existante (mettons rectangle) qui n'existe pas dans l'interface, tu sais
au moins que cette classe rectangle existe, tu peux donc en définir une
sous-classe et ajouter ton traitement.
Avatar
Wykaaa
Francois a écrit :
Wykaaa a écrit :

J'implémente les enum en Java, de la façon suivante car je n'aime pas
les "switch" : [...]



Ce n'était pas le sens de ma question initiale car ma question initiale
était plutôt : "si on devait implémenter fidèlement un enum basique
comme Etat en Java version 1.4 (ou moins), il faudrait écrire quoi ?".
Mais en fait, à moins que j'ai dit une grosse bêtise dans le message 2
du fil, je pense que cette question est plus ou moins réglée.



Je suis d'accord avec toi que j'ai légèrement dévié ;-)

Du coup, votre discussion sur des problèmes de "conception" (je ne sais
pas si c'est le bon terme) m'intéresse beaucoup. Alors, allons y... :-)



J'ai l'impression que tu peux apprendre des choses (même si elles ne
sont pas vraiment en rapport avec ton post initial, ce dont je te pris
de m'excuser...)

Rappelez-vous ceci :
La chasse au switch est à la programmation objet ce que la chasse au
goto est à la programmation structurée !

Il n'y a jamais besoin de switch en programmation objet si on utilise
un langage objet correctement, c'est-à-dire en utilisant le
polymorphisme.



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.



Qu'est-ce qui est flou pour toi ?
Remplacer les switch par le polymorphisme est la façon la plus naturelle
d'introduire l'héritage dans une programmation. Il faut que ceci ait été
prévu dès la conception car on ne trafique jamais le code impunément...

Après, sur la question des enum, leur associer des traitements n'est-il
pas aller au delà de la fonction initiale des enum ? J'ai un peu lu la
suite de la discussion et je suis un peu d'accord (je n'affirme rien
bien sûr) avec ce que disait Samuel sur le point suivant : les enum sont
un moyen sûr de disposer d'un type prenant un ensemble fini de valeurs
auto-documentées et c'est à peu près tout. Si l'on veut associer des
traitements à ces valeurs, alors il me semble qu'il faudrait plutôt
s'orienter vers des classes en bonnes et dues formes. Mais je peux me
tromper. :-)



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...
Et bonjour, pour modifier les centaines de switch, si tu ajoute une
valeur à ton enum ;-)
Remarque que beaucoup font comme ça et que c'est pour ça que les
programmes sont difficilement maintenables et évolutifs et qu'il faut
les jeter au bout de 4 ou 5 versions...
On ne peut pas se permettre ce genre d'attitude sur des logiciels qui
font des millions de lignes de code et qui ont une durée de vie de
plusieurs dizaines d'années.
1 2 3 4 5