Surchage des méthodes : type de retour

Bonjour,

J'ai toujours pensé qu'il n'était pas possible de surchager une fonction en changeant son type de retour.

C'est d'ailleurs ce que j'avais compris dans "penser en java" :

Citation:

---

void f() {}
int f() {}

(...)

Comment Java peut-il déterminer quelle méthode f( ) doit être exécutée ? Et comment quelqu'un lisant ce code pourrait-il le savoir ? A cause de ce genre de difficultés, il est impossible d'utiliser la valeur de retour pour différencier deux méthodes Java surchargées

---

Pourtant dans la FAQ sur les surchages, il est écrit :

Citation:

---

C'est le fait de déclarer plusieurs méthodes avec le même nom mais avec des paramètres et/ou type de retour différents.

---

Le pire, c'est que j'ai passé un test d'embauche en Java hier soir, qu'il y avait une question sur le changement de type de retour pour une surchage, et que du coup je me chie dessus d'avoir planté une question probablement éliminatoire (effectivement, on se présente pas ingénieur R&D java si on est pas foutu de faire une surcharge)

Merci d'éclairer ma lanterne :/

Citation:

---

Envoyé par Faiche

...
Merci d'éclairer ma lanterne

---

Si tu insistes... ;)

Citation:

---

getMethod

public Method getMethod(String name,
Class... parameterTypes)
throws NoSuchMethodException,
SecurityException Returns a Method object that reflects the specified public member method of the class or interface represented by this Class object. The name parameter is a String specifying the simple name the desired method. The parameterTypes parameter is an array of Class objects that identify the method's formal parameter types, in declared order. If parameterTypes is null, it is treated as if it were an empty array. If the name is "<init>"or "<clinit>" a NoSuchMethodException is raised. Otherwise, the method to be reflected is determined by the algorithm that follows. Let C be the class represented by this object:

1. C is searched for any matching methods. If no matching method is found, the algorithm of step 1 is invoked recursively on the superclass of C.
2. If no method was found in step 1 above, the superinterfaces of C are searched for a matching method. If any such method is found, it is reflected.

To find a matching method in a class C: If C declares exactly one public method with the specified name and exactly the same formal parameter types, that is the method reflected.
If more than one such method is found in C, and one of these methods has a return type that is more specific than any of the others, that method is reflected; otherwise one of the methods is chosen arbitrarily. See The Java Language Specification, sections 8.2 and 8.4.

Parameters:name - the name of the methodparameterTypes - the list of parameters Returns:the Method object that matches the specified name and parameterTypes Throws: NoSuchMethodException - if a matching method is not found or if the name is "<init>"or "<clinit>". NullPointerException - if name is null SecurityException - If a security manager, s, is present and any of the following conditions is met:

• invocation of s.checkMemberAccess(this, Member.PUBLIC) denies access to the method
• the caller's class loader is not the same as or an ancestor of the class loader for the current class and invocation of s.checkPackageAccess() denies access to the package of this class

Since:JDK1.1

---

Salut,

Citation:

---

Envoyé par Faiche

J'ai toujours pensé qu'il n'était pas possible de surchager une fonction en changeant son type de retour.

---

Il n'est effectivement pas possible de faire une surcharge en changeant seulement le type de retour.

Disons qu'il faudrait reformuler la phrase de la FAQ :

Citation:

---

C'est le fait de déclarer plusieurs méthodes avec le même nom mais avec des paramètres différents (et éventuellement un type de retour différents).

---

Ainsi, on a le droit de faire ceci :

Code:

---

1 2 3

void f() {}   int f(int i) {}

---

Citation:

---

Envoyé par Faiche

Le pire, c'est que j'ai passé un test d'embauche en Java hier soir, qu'il y avait une question sur le changement de type de retour pour une surchage, et que du coup je me chie dessus d'avoir planté une question probablement éliminatoire (effectivement, on se présente pas ingénieur R&D java si on est pas foutu de faire une surcharge)

---

Le changement du type de retour seul ne permet pas de faire une surcharge... J'espère que c'est bien ce que tu as répondu !


a++

Ah meeerde

Pourquoi un truc est permi si de toutes façons c'est toujours la même méthode qui est appellée ? Parce que arbitraire c'est différent de au hazard, ce qui veut dire que ce sera toujours la même du coup.

Putain le vieux piège

Edit : Ah, c'est pire ! Parce que le choix était entre "2 fonctions au même nom avec params différents" et "2 fonctions au même nom avec param et/ou type de retour différents" et j'ai coché le premier

bon, j'ai l'air con maintenant

C'est un peu plus compliqué finalement...

Tu ne peux pas créer 2 méthodes avec les mêmes paramètres mais un type retour différent dans la même classe...
Tu peux par contre déclarer une méthode qui a les mêmes paramètres qu'une méthode d'une super-classe et un type retour différent !

Youpieeeee :fou:

Je pensais que surcharge (overload) c'est dans la même classe, et redéfinition (override) c'est par héritage.

Donc pour récapituler :

meme type de retour param différent = surcharge
type de retour différent mm param = crackage
type de retour différent param différent = surcharge

c'est bien ça ?

Voilà ce que j'ai trouvé à ce sujet...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

overloaded methods: 1. appear in the same class or a subclass 2. have the same name but, 3. have different parameter lists, and, 4. can have different return types Overriding methods * late-binding also supports overriding * overriding allows a subclass to re-define a method it inherits from it's superclass * overriding methods: 1. appear in subclasses 2. have the same name as a superclass method 3. have the same parameter list as a superclass method 4. have the same return type as as a superclass method 5. the access modifier for the overriding method may not be more restrictive than the access modifier of the superclass method o if the superclass method is public, the overriding method must be public o if the superclass method is protected, the overriding method may be protected or public o if the superclass method is package, the overriding method may be packagage, protected, or public o if the superclass methods is private, it is not inherited and overriding is not an issue 6. the throws clause of the overriding method may only include exceptions that can be thrown by the superclass method, including it's subclasse

---

Bon, ok, j'ai faux donc

\o/

Citation:

---

Envoyé par Faiche

Edit : Ah, c'est pire ! Parce que le choix était entre "2 fonctions au même nom avec params différents" et "2 fonctions au même nom avec param et/ou type de retour différents" et j'ai coché le premier

---

Non c'était bien la bonne réponse !
La seconde réponse insinue qu'on peut seulement changer le type de retour ce qui est faux !

Citation:

---

Envoyé par OButterlin

Tu peux par contre déclarer une méthode qui a les mêmes paramètres qu'une méthode d'une super-classe et un type retour différent !

---

Pas complètement différent : le type doit correspondre à un type fils du type de retour de la méthode parente. Pour info cela s'appelle la covariance (FAQ : Quelles sont les règles à respecter pour redéfinir/implémenter une méthode ?).


D'ailleurs si on regarde la Javadoc de Java 6 on a plus d'info : getMethod

Citation:

---

Note that there may be more than one matching method in a class because while the Java language forbids a class to declare multiple methods with the same signature but different return types, the Java virtual machine does not. This increased flexibility in the virtual machine can be used to implement various language features. For example, covariant returns can be implemented with bridge methods; the bridge method and the method being overridden would have the same signature but different return types.

---

En clair : Bien que le langage Java interdisent la déclaration de méthode avec la même signature mais un type de retour différent, ceci est autorisé par la JVM au niveau du bytecode.
:arrow: Cela pourrait être potentiellement utilisé par d'autres langages.
:arrow: C'est utilisé par le langage Java pour gérer la covariance justement (en fait le compilateur génèrera une seconde méthode identique avec l'ancien type de retour)


a++

Citation:

---

Envoyé par adiGuba

Pas complètement différent : le type doit correspondre à un type fils du type de retour de la méthode parente. Pour info cela s'appelle la covariance (FAQ : Quelles sont les règles à respecter pour redéfinir/implémenter une méthode ?).

---

En complément...

D'après les tests que j'ai fait, on peut changer le type de retour sans utiliser un type fils mais via une interface commune

A+

Citation:

---

Envoyé par OButterlin

D'après les tests que j'ai fait, on peut changer le type de retour sans utiliser un type fils mais via une interface commune

---

Oui pour une interface il suffit de l'implémenter en effet.

Que penses-tu de cette correction :

Citation:

---

La version 5.0 de Java apporte une nouvelle possibilité : on peut désormais modifier le type de retour de la méthode. Toutefois, afin de ne pas rompre le contrat, il faut que le nouveau type soit assignable au type de retour d'origine. En clair :

• Si le type d'origine est une classe, le nouveau type devra correspondre à une classe fille.
• Si le type d'origine est une interface, le nouveau type devra correspondre soit à une interface fille, soit à une classe implémentant l'interface d'origine.

---

a++

Citation:

---

Envoyé par adiGuba

Oui pour une interface il suffit de l'implémenter en effet.

Que penses-tu de cette correction :


a++

---

Je la préfère (plus conforme à la réalité et plus complète) :king: