¿Sobrecarga con diferentes tipos de retorno en Java?


104

¿Por qué no es posible sobrecargar una función simplemente cambiando el tipo de retorno? ¿Cambiará eso en una versión futura de Java?

Por cierto, solo como referencia, ¿es esto posible en C ++?



KNU, ​​la otra respuesta difiere en que formula la pregunta en términos generales, no específicos del idioma. También es interesante que la respuesta aceptada de otras preguntas va más allá al especificar que Java JVM permite que se haga con la manipulación de componentes internos.
J Woodchuck

Respuestas:


157

No puede hacerlo en Java y no puede hacerlo en C ++. La razón es que el valor de retorno por sí solo no es suficiente para que el compilador averigüe qué función llamar:

public int foo() {...}
public float foo() {..}

...
foo(); // which one?

3
Siempre pensé que si hacíamos algo como int i = foo () o float f = foo () sabría cuál, pero si la declaración es solo la función que el compilador no sabría. Lo sé. Gracias.
nunos

7
@nunos incluso si fuera float f = foo (), el compilador no podría resolverlo porque tanto un int serían entradas válidas para un float. Compare el flotador f = 7; (¿7 es un flotante o un int?)
NomeN

5
@NomeN Pero su declaración sugiere que func (int i) y func (float i) serían indistinguibles para el compilador, y todos sabemos que esto no es cierto. La verdadera razón la da Oded (vea la siguiente respuesta): se trata de la firma del método. Y, por cierto. 7 es definitivamente un número entero mientras que 7.0 o 7f es flotante ;-)
Ta Sas

7
7.0 no lo es float, lo es double.
fredoverflow

3
El hecho de que foo();sin un tipo de retorno sea ambiguo no es necesariamente una razón para no permitirlo como una sobrecarga. Hay argumentos que pueden causar ambigüedad (por ejemplo foo(null);), pero eso no hace que la sobrecarga sea inherentemente inválida.
shmosel

48

La razón es que las sobrecargas en Java solo se permiten para métodos con diferentes firmas .

El tipo de retorno no forma parte de la firma del método, por lo que no se puede usar para distinguir sobrecargas.

Consulte Definición de métodos de los tutoriales de Java.


4
Pero, ¿por qué el tipo de devolución no forma parte de la firma
Y el

51
oh "solo porque"! Veo.
andho

3
El tipo de retorno ES parte de la firma del método. Solo mire el desmontaje de la clase.
konmik

2
Realmente no es @konmik, no según las reglas de sobrecarga de métodos. Intentalo. Mismo nombre de método, mismos tipos de parámetros en el mismo orden, diferentes tipos de devolución. No se compilará.
Oded

3
Sí, porque el tipo de devolución no forma parte de la firma . La firma es: el nombre del método + los tipos y el orden de su parámetro. Lea el enlace que proporcioné en mi respuesta: "La firma del método declarado anteriormente es: calculateAnswer(double, int, double, double)". Vea que el tipo de retorno no esté incluido, @konmik.
Oded

22

Antes de Java 5.0, cuando se reemplaza un método, tanto los parámetros como el tipo de retorno deben coincidir exactamente. En Java 5.0, introduce una nueva función denominada tipo de retorno covariante. Puede anular un método con la misma firma pero devuelve una subclase del objeto devuelto. En otras palabras, un método en una subclase puede devolver un objeto cuyo tipo es una subclase del tipo devuelto por el método con la misma firma en la superclase.


3
Estaba desconcertado cuando vi esto por primera vez. ¡Gracias por explicar por qué esto es posible!
Dylan Knowles

2
la sobrecarga y la anulación son diferentes. La sobrecarga no implica (necesariamente) herencia
senseiwu

3
Esta respuesta puede parecer engañosa para un novato en Java, porque no es relevante con la sobrecarga en absoluto, es primordial , completamente diferente.
azizbekian

4

Overloaded Los métodos en java pueden tener diferentes tipos de retorno dado que el argumento también es diferente.

Mira el código de muestra.

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");
    }

}

básicamente no se tiene en cuenta el tipo de retorno, solo los argumentos, tristes pero ciertos
Alexander Mills

1

El compilador no considera el tipo de retorno al diferenciar los métodos, por lo que no puede declarar dos métodos con la misma firma incluso si tienen un tipo de retorno diferente.


1

El tipo de retorno no importa mientras se sobrecarga un método. ¡Solo tenemos que asegurarnos de que no haya ambigüedad!

La única forma en que Java puede saber qué método llamar es diferenciando los tipos de la lista de argumentos. Si el compilador permitiera dos métodos con el mismo nombre y los mismos tipos de argumentos, no habría forma de determinar cuál debería llamar.


0

El compilador no considera el tipo de retorno al diferenciar los métodos, por lo que no puede declarar dos métodos con la misma firma incluso si tienen un tipo de retorno diferente.

Si está al tanto de la ejecución de la función, entonces sabrá que cuando llamamos a una función, la parte de la definición se ejecuta y finalmente requerimos la declaración de retorno, por lo tanto, podemos decir que el retorno viene después de la definición completa de la función, por eso si hay dos o más funciones con el mismo nombre y con el mismo tipo y no. de argumentos en el momento de llamar, cómo el compilador sabrá sobre cuál llamar, porque el nombre de la función y los parámetros son los mismos. En el momento de llamar, en primer lugar, todo el enfoque estará en los argumentos y el nombre de la función y, después de completar la definición de la función, por fin nos ocuparemos de la declaración de retorno.

Compile Time Error es mejor que Run Time Error. Por lo tanto, el compilador de Java muestra un error de tiempo del compilador si declara que el mismo método tiene los mismos parámetros.


¿En qué se diferencia esto de la respuesta aceptada? (También la razón por la que es un error de tiempo de compilación es porque el compilador no puede averiguar a qué método llamar, entonces, ¿cómo se supone que debe generar el código ejecutable adecuado?)
UnholySheep

-2

no, no es realmente posible de esa manera, solo puede sobrecargar por el número de argumentos o el tipo de datos de los argumentos

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.