Motivo técnico para no tener parámetros predeterminados en Java

Question

He estado buscando para encontrar el razonamiento detrás de los parámetros predeterminados para las funciones en Java.

Soy consciente de que es posible simular el comportamiento, ya sea con varargs o creando varias funciones sobrecargadas que acepten menos parámetros, y llame a la función real que toma todos los parámetros. Sin embargo, ninguna de estas opciones concuerda con la claridad y la facilidad de uso de, por ej. Sintaxis de C++

¿Alguien sabe si hay una razón técnica sólida que haría algo así como

void myFunc(int a=1, int b=2) {...} 

indeseable o deshacer-poder en una nueva versión de Java?

Answer 1

No conozco un motivo técnico, aparte de que es complicado qué valores se están omitiendo y cuáles no.

Por ejemplo, en su muestra, si solo se transmitió un entero, ¿es a o b el que debe ser predeterminado? Lo más probable es a, pero agrega ese nivel de ambigüedad.

Una solución sencilla sería la de

void myFunc(Integer a, Integer b) { 
    if (a == null) a = 1; 
    if (b == null) b = 2; 

} 

Sí se aliento más largo, y sí que oculta el incumplimiento dentro del código, en lugar de la firma del método (que podría ser mostrado en JavaDoc), pero hace cumplir la consistencia.

Answer 2

No estaba en la versión inicial de Java porque decidieron que no lo necesitaban, probablemente para mantener las cosas simples.

Agregarlo ahora sería complicado, porque debe hacerse de manera compatible con versiones anteriores. La adición de varargs, autoboxing y genéricos en Java5 fue una empresa importante, y solo se podía hacer con funcionalidad limitada (como borrado de tipos) y a costa de una mayor complejidad (las nuevas reglas de resolución de métodos son buenas preguntas para el examen).

Su mejor oportunidad sería con un lenguaje que no sea Java en la JVM. Tal vez uno de ellos ya tiene esto.

Answer 3

Acepto que los argumentos opcionales agregarían una gran claridad y ahorrarían el enorme trabajo de definir cargas de métodos sobrecargados (llamados telescoping), que no hacen nada más que llamarse entre sí. Sin embargo, el habilitador para esta característica clara es passing arguments by name.

La asociación designada es autodidacta. Por el contrario, la asociación de argumentos posicionales es concisa, pero hace que se consulte la definición de método todo el tiempo para verificar qué argumento se espera en n esta posición en cada invocación. Esto es ridículo y nos motiva a buscar soluciones como Builder pattern. The Builder en realidad resuelve ambos problemas a la vez porque la asociación con nombre es un sinónimo de argumentos opcionales. Pero Builder es útil solo para el usuario. El diseñador de API aún debe perder espacio/tiempo para crear la clase de Constructor. Los fanáticos del patrón pueden estar en desacuerdo, pero es una exageración crear una clase de Constructor para cada método con argumentos nombrados/opcionales. El diseño del lenguaje debería obviar este estúpido patrón. Pero no sé qué tan compatibles son con la lista de argumentos variables.

Answer 4

Para evitar la ambigüedad. Reemplazo del método de soporte de Java.

Asumimos el código de abajo:

public int add(int a) { 
    // do something 
} 

public int add(int a, int b = 0) { 
    // do something 
} 

Cuando llamamos add(12), ¿Me puede decir qué función se invoca?