Discussion :

[boobi]

Salut à tous,
Je suis en train de lire un article sur java ou on parle de la signature d'une méthode.
Est ce que la signature c'est par exemple la valeur de x renvoyé par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
public int GetX() {return x;}

Merci d'avance.

[ Modéré par SEMPERE Benjamin ]
Ajout d'un tag dans le titre
Modification du titre
Ajout des balises code
Les Règles du Forum

[biozaxx]

salut ,

la signature c'et la description des parametres que tu fournis à ta methode:

tu peux avoir dans ta classe plusieurs methodes avec le même nom si les signatures sont differentes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
 
public String maMethode(ArrayList list){}
 
public String maMethode(String arg1, String arg2){}

[SEMPERE Benjamin]

salut ,

la signature c'et la description des parametres que tu fournis à ta methode:

tu peux avoir dans ta classe plusieurs methodes avec le même nom si les signatures sont differentes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
 
public String maMethode(ArrayList list){}
 
public String maMethode(String arg1, String arg2){}

oui dans ce cas la, on parle d'overloading de méthode. Un méthode en Java est identifié par:

- Sa classe d'appartenance (package inclus) ex: "com.toto.project.Classe"
- Son nom ex: "maMethode"
- Sa liste d'aguments (nombre et type)

[boobi]

Merci beaucoup pour vos réponses, maintenant tout est clair !

Merci aussi à l'admin pour la modération je recommencerai plus

[BainE]

bonjour,
juste une précision il me semble que le type de retour ne fait pas partie de la signature non ???

[SEMPERE Benjamin]

bonjour,
juste une précision il me semble que le type de retour ne fait pas partie de la signature non ???

oui tout à fait, cela découle de ce que j'ai ecrit plus haut (en esperant que boobi ait fait le discernement )

[adiGuba]

bonjour,
juste une précision il me semble que le type de retour ne fait pas partie de la signature non ???

En effet le type de retour ne fait pas partie de la signature :

- Sa classe d'appartenance (package inclus) ex: "com.toto.project.Classe"
- Son nom ex: "maMethode"
- Sa liste d'aguments (nombre et type)

C'est d'ailleurs la raison pour laquelle on ne peut pas avoir le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
public Integer getValue() { return iValue; }
public Float getValue() { return fValue; }

car les deux méthodes ont la même signature...

Une exception toutefois, le compilateur (java 5.0 seulement il me semble) peut ajouter des méthodes avec la même signature mais un type de retour différent...

a++

[SEMPERE Benjamin]

Une exception toutefois, le compilateur (java 5.0 seulement il me semble) peut ajouter des méthodes avec la même signature mais un type de retour différent...

a++

Salut, je ne crois pas qu'on peut avoir un overloading autorisé si
le nom de la méthode et ses arguments sont identiques et que le type de retour est différent.

[SEMPERE Benjamin]

Il est vrai que cela est possible lors de l'overriding (règles sur les types covariant)

exemple dans la superclasse:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
public SimpleDateFormat getDateFormat(...){
 
...
return...;
}

dans la sousclasse:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
public DateFormat getDateFormat(...){
 
...
return...;
}

Ici l'overrriding est autorisé (Uniquement avec Java5!!!)

[adiGuba]

@SEMPERE Benjamin >> Justement lorsque tu modifies le type de retour dans la sous-classe, le compilateur rajoute automatiquement la méthode avec le type de retour 'original' qui se contente d'appeller la première... Ceci afin de rester compatible avec les définitions de la classe/interface parente...

Si tu listes les méthodes avec l'API de reflection tu verras que tu obtiens bien deux méthodes différentes (une qui retourne un DateFormat et l'autre un SimpleDateFormat).

Note : dans ton exemple tu as inversé la classe-fille et la super-classe car le type de retour de la méthode de la classe fille doit être une spécialisation de celui de la classe mère (ie: dans la méthode classe fille tu peux retourner un SimpleDateFormat si la classe mère renvoit un DateFormat puisque SimpleDateFormat étend DateFormat).

Et il peut y avoir le même cas lorsqu'on hérite/implemente avec les Generics lorsqu'on spécifie le type exact du paramétrage de la sous-classe/interface...

Mais bon tout cela est presque hors-sujet...

a++

[SEMPERE Benjamin]

Note : dans ton exemple tu as inversé la classe-fille et la super-classe car le type de retour de la méthode de la classe fille doit être une spécialisation de celui de la classe mère (ie: dans la méthode classe fille tu peux retourner un SimpleDateFormat si la classe mère renvoit un DateFormat puisque SimpleDateFormat étend DateFormat).

Oui effectivement j'ai inversé les deux
Je suis allé trop vite...

je me corrige de ce pas:
Il est vrai que cela est possible lors de l'overriding (règles sur les types covariant)

exemple dans la superclasse:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
public DateFormat getDateFormat(...){
 
...
return...;
}

dans la sousclasse:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
public SimpleDateFormat getDateFormat(...){
 
...
return...;
}

Ici l'overrriding est autorisé (Uniquement avec Java5!!!)