[INFO]Signature d'une méthode

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:

---

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
:arrow: Les Règles du Forum

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:

---

1 2 3 4 5

public String maMethode(ArrayList list){}   public String maMethode(String arg1, String arg2){}

---

Citation:

---

Envoyé par 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:

---

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)

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

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

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

Citation:

---

Envoyé par BainE

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 ) :wink:

Citation:

---

Envoyé par BainE

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 :

Citation:

---

Envoyé par SEMPERE Benjamin

- 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:

---

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++

Citation:

---

Envoyé par adiGuba

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.

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

exemple dans la superclasse:

Code:

---

1 2 3 4 5 6

public SimpleDateFormat getDateFormat(...){   ... return...; }

---

dans la sousclasse:

Code:

---

1 2 3 4 5 6

public DateFormat getDateFormat(...){   ... return...; }

---

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

@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++

Citation:

---

Envoyé par adiGuba

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 :wink:
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:

---

1 2 3 4 5 6

public DateFormat getDateFormat(...){   ... return...; }

---

dans la sousclasse:

Code:

---

1 2 3 4 5 6

public SimpleDateFormat getDateFormat(...){   ... return...; }

---

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