Envoyé par
tinico
oula oui !!
C'est meme moins lisible !! hi hi
J'avais prévenu
Cette solution à toutefois quelques avantages (tant que j'y suis je développe ) :
- Elle permet de définir des restrictions sur les types autorisé sans pour autant qu'il y ait de relation entre les deux. Par exemple si on souhaite accepter seulement les type String et Date il suffit d'utiliser la surcharge de méthode, par exemple :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
| // Ajout de paramètre (private pour qu'elle ne puisse pas être utilisé directement:
private VarArg addObject(Object arg) {
this.paramList.add(arg);
return this;
}
// On autorise l'ajout de paramètre de type String
public VarArg add(String arg) {
return this.addObject(arg);
}
// On autorise l'ajout de paramètre de type Date
public VarArg add(Date arg) {
return this.addObject(arg);
} |
- Elle permet également de gérer les types primitives de manière transparente (en gérant une espèce d'autoboxing). Ceci encore une fois avec la surcharge de méthode :
1 2 3 4
| // Ajout de paramètre de type int :
public VarArg add(int arg) {
return add(new Integer(arg));
} |
Mais il faut également dire que la première solution a un gros avantage : elle sera très facile à migrer vers Java 5.0 !!!
Exemple de code Java 1.4 :
1 2 3
| public void method(Object[] args) {
...
} |
Qui est appelé comme cela :
obj.method( new Object[] { param1, param2, param3, param4 } );
Et pour pouvoir utiliser l'ellipse de Java 5.0 il suffira de modifier la déclaration du tableau dans la méthode :
public void method(Object... args) {
Comme l'ellipse est en fait un tableau il n'y aura rien à changer dans le code de la méthode, et on pourra alors utiliser la syntaxe courte :
obj.method( param1, param2, param3, param4 );
Mais le principal avantage vient du fait que l'ancienne syntaxe continuera de fonctionner sans problèmes :
obj.method( new Object[] { param1, param2, param3, param4 } );
Il sera inutile de modifier tous les appels de méthodes existants
a++
Partager