[Debutant(e)]définir les valeurs possibles d'un param

J'ai une méthode :
public donneeSortie read(donneeEntree dE, String comportement)
où le paramètre comportement définit l'action qui sera effectuée pour remplir mon donneeSortie avant de faire le return.
Comportement peut prendre 3 (et seulement 3) valeurs différentes : ABT, NUL, DEF.

Je voudrais pouvoir empecher les utilisateurs de mettre autre chose dans comportement quand ils font appel à cette méthode en ne leur proposant que les 3 valeurs possibles et en générant une erreur s'ils mettent autre chose.

Je voulais utiliser des static final string dans ma classe, dire de les utiliser dans la javadoc et renvoyer une exception quand comportement contient autre chose mais ça plaît pas à mon chef (qui est un pro VB et qui m'a dit qu'on pouvait faire ça simplement en VB alors qu'il fallait que j'arrive à faire pareil en java :evil: !!!).





[Modéré par Didier]
Ajout de tag dans le titre
Lire les règles du forum : Règles du forum Java

Salut,

Il faut utiliser des énumération.

Si tu utilises Java 1.4 ou inférieur, tu as un exemples dans la FAQ :
http://java.developpez.com/faq/java/?page=divers#LANGAGE_enumeration
Je pense que la solution numéro 2 est la plus approprié.

C'est assez similaire à l'utilisation de String final static mais cela te permet de bloquer à la compilation les autres valeurs...

Si tu utilises java 1.5, je te conseilles de jeter un coups d'oeil à l'article de Lionel Roux sur les nouveautés de Java 1.5, et en particulier la partie sur les énumérations

a++

[edit]
J'ai oublié de préciser que si tu utilises Java 1.5 et le type enum, tu perds toute compatibilité avec les JVM inférieur...

J'utilise java 1.4, la solution n°2 a l'air de faire ce que je veux. Si je comprends bien le fonctionnement, pour moi ça donnerait :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public final class comportement { private comportement() { /** Rien à faire */ }   /** liste des valeurs */ public final static comportement ABT = new comportement(); public final static comportement DEF = new comportement(); public final static comportement NUL = new comportement(); }

---

et pour ma méthode :

Code:

---

1 2 3 4 5 6

public donneeSortie read(donneeEntree dE, comportement comport){ ...   return donneeSortie }

---

et quand on utilise la méthode :

Code:

---

1 2	read(dEntree, comportement.ABT);

---

Par contre comment je fais pour tester quel comportement a été saisi ?

Tu peux faire une succession de if/else pour différencier les différents cas :

Code:

---

1 2 3 4 5 6 7 8 9

if (comport == null) { // Si null est passé en paramètre } else if (comport == comportement.ABC) { // Cas ABC } else if (comport == comportement.DEF) { // Cas DEF } else if (comport == comportement.NUL) { // Cas NUL }

---

N'oublie pas de gerer le cas de null car rien n'empeche celui qui utilise ta méthode de faire :

Code:

---

1 2	read(dEntree, null);

---

Si tu ne veux pas faire un cas supplémentaire pour null, tu peux l'assigner à une de tes valeurs :

Code:

---

public final static comportement NUL = null

---

Dans ce cas les deux appels suivant seront équivalent :

Code:

---

1 2	read(dEntree, null); read(dEntree, comportement.NUL);

---

a++

PS : En général les noms de Classe commencent par une majuscule !

je pense que pour etre sur que l'utilisateur ne choisit pas de comprtement autre que ceux que tu veux je te suggere de les générés pour l'utilisateur à l'execution.

avec un peu d'héritage et le pattern Factory tu devrait y arriver. Si tu veux plus d'info, dis-le et je te repondrais....mais je te laisse chercher un peu d'abord, c tj mieux et plus gratifiant de trouver par soi même ;-)

waddle

--
EPITA Student
Promo 2006

Si tu es prêt à taper quelques lignes de code en plus, tu peux définir ta classe de la façon suivante :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public class Comportement { public static final int ABT_VALUE = 0; public static final int DEF_VALUE = 1; public static final int NUL_VALUE = 2;   public static final EdfaCurveType ABT = new EdfaCurveType(ABT_VALUE); public static final EdfaCurveType DEF = new EdfaCurveType(DEF_VALUE); public static final EdfaCurveType NUL = new EdfaCurveType(NUL_VALUE);   public final int value;   private Comportement(int value) { this.value = value; } }

---

Cela te permettra de l'utiliser de façon un peu plus lisible avec un switch case :

Code:

---

1 2 3 4 5 6 7 8 9

void foo(Comportement c) { switch (c.value) { case Comportement.ABT_VALUE : abt(); break; case Comportement.DEF_VALUE : def(); break; case Comportement.NUL_VALUE : nul(); break; } }

---

[ Modéré par Bulbo ]
Ajout des balises code
:arrow: Les Règles du Forum

Comme j'ai pas internet au boulot :cry: , j'ai utilisé la méthode qu'adiGuba m'a posté hier soir (et ça fonctionne très bien). Mais je garde quand même celle de JPigKeud sous le bras parceque pouvoir utiliser le switch c pas mal. Par contre, j'ai pas compris où voulais en venir waddle.

En tout cas merci à tous pour votre rapidité. :D

je te conseillerai de faire un heritage entre tes comportements:

public abstract class Comportement ....

public class Abt extends Comportement ....

.....

apres a cote tu crés une factory (pattern Factory)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

public class ComportementFactory { public Comportement create(String configuration) { if (configuration.equals ("toto") return new Abt(); else if ...... ........... else throw new MyExceptionDunCasInconnu(); } }

---

le string configuration passer en parametre a create peut etre autre chose qu'un String si tu veux.

avantages de cette methode, en cas d'ajout d'un nouveau comportement il te suffit de le sous classer de Comportement et de rajouter un cas dans ton create. et c tout.

en plus, ici l'heritage pourrait te servir par exemple a definir des methodes abstraites dans comportement afin de definir ce que doivent faire les differents comportements (actuels ou futurs).

cette definition de methode abstraite te permet de separer le code metier du code d'un comportement (puisqu'il respectent tous la meme API definie dans Comportement). De plus, le code metier se fou du comportement qu il manipule donc la correlation est faible (c mieux). Et l ajout de nouveaux comportement ne touche pas a ton code metier.

le pattern Factory peut d'ailleur etre combiné avec le pattern Singleton dans le cas ou plusieurs classes ont besoin de cette factory et que les instances n'ont pas de sens dans leur utilisation.

waddle

--
EPITA Student
Promo 2006