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() {}
}
//---------------------------
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() {}
}
//---------------------------
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.).
Ç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.).
Ç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.).
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.
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.
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.
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".
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".
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".
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.
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.
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.
Si tu as plusieurs centaines de traitements différents pour un enum, il
y a un sérieux problème de conception !!
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.
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.
Si tu as plusieurs centaines de traitements différents pour un enum, il
y a un sérieux problème de conception !!
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.
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.
Si tu as plusieurs centaines de traitements différents pour un enum, il
y a un sérieux problème de conception !!
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.
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.
J'implémente les enum en Java, de la façon suivante car je n'aime pas
les "switch" : [...]
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.
J'implémente les enum en Java, de la façon suivante car je n'aime pas
les "switch" : [...]
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.
J'implémente les enum en Java, de la façon suivante car je n'aime pas
les "switch" : [...]
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.
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 :)
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 :)
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 :)
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. :-)
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. :-)
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. :-)