Pourquoi n'est-il pas possible de surcharger une fonction simplement en modifiant le type de retour? Cela changera-t-il dans une future version de Java?
Au fait, juste pour référence, est-ce possible en C ++?
Pourquoi n'est-il pas possible de surcharger une fonction simplement en modifiant le type de retour? Cela changera-t-il dans une future version de Java?
Au fait, juste pour référence, est-ce possible en C ++?
Réponses:
Vous ne pouvez pas le faire en Java et vous ne pouvez pas le faire en C ++. La raison en est que la valeur de retour seule n'est pas suffisante pour que le compilateur détermine quelle fonction appeler:
public int foo() {...}
public float foo() {..}
...
foo(); // which one?
float
, c'est double
.
foo();
sans un type de retour serait ambigu n'est pas nécessairement une raison pour l'interdire en tant que surcharge. Il y a des arguments qui peuvent provoquer une ambiguïté (par exemple foo(null);
), mais cela ne rend pas la surcharge intrinsèquement invalide.
La raison en est que les surcharges en Java ne sont autorisées que pour les méthodes avec des signatures différentes .
Le type de retour ne fait pas partie de la signature de la méthode et ne peut donc pas être utilisé pour distinguer les surcharges.
Voir Définition de méthodes à partir des didacticiels Java.
calculateAnswer(double, int, double, double)
". Vérifiez que le type de retour n'est pas inclus, @konmik.
Avant Java 5.0, lorsque vous remplacez une méthode, les paramètres et le type de retour doivent correspondre exactement. Dans Java 5.0, il introduit une nouvelle fonctionnalité appelée type de retour covariant. Vous pouvez remplacer une méthode avec la même signature mais renvoie une sous-classe de l'objet renvoyé. En d'autres termes, une méthode dans une sous-classe peut retourner un objet dont le type est une sous-classe du type renvoyé par la méthode avec la même signature dans la superclasse.
Overloaded
Les méthodes en java peuvent avoir des types de retour différents étant donné que l'argument est également différent.
Consultez l'exemple de code.
public class B {
public String greet() {
return "Hello";
}
//This will work
public StringBuilder greet(String name) {
return new StringBuilder("Hello " + name);
}
//This will not work
//Error: Duplicate method greet() in type B
public StringBuilder greet() {
return new StringBuilder("Hello Tarzan");
}
}
Le type de retour n'a pas d'importance lors de la surcharge d'une méthode. Nous devons simplement nous assurer qu'il n'y a pas d'ambiguïté!
La seule façon pour Java de savoir quelle méthode appeler est de différencier les types de la liste d'arguments. Si le compilateur autorisait deux méthodes avec le même nom et les mêmes types d'arguments, il n'y aurait aucun moyen de déterminer laquelle il devrait appeler.
Le compilateur ne prend pas en compte le type de retour lors de la différenciation des méthodes, vous ne pouvez donc pas déclarer deux méthodes avec la même signature même si elles ont un type de retour différent.
Si vous êtes au courant de l'exécution de la fonction, vous serez conscient que lorsque nous appelons une fonction, la partie de définition s'exécute et, enfin, nous avons besoin de l'instruction return, donc nous pouvons dire que return vient après toute la définition de la fonction, c'est pourquoi s'il y en a deux ou plus de fonctions avec le même nom et avec le même type et non. d'arguments au moment de l'appel, comment le compilateur saura lequel appeler, car le nom et les paramètres de la fonction sont les mêmes. Au moment de l'appel, tout d'abord, l'accent sera mis sur les arguments et le nom de la fonction et après l'achèvement de la définition de la fonction, nous traiterons enfin de l'instruction return.
L'erreur de temps de compilation est meilleure que l'erreur d'exécution. Ainsi, le compilateur java génère une erreur de temps du compilateur si vous déclarez la même méthode avec les mêmes paramètres.
non pas vraiment possible de cette façon vous ne pouvez surcharger que par aucun argument ou type de données des arguments