tipos - Razón técnica para no tener parámetros por defecto en Java

return java

Question

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

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

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

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

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

Answer 1

Estoy de acuerdo en que los argumentos opcionales agregarían una gran claridad y salvarían el enorme trabajo de definir un montón de métodos sobrecargados (llamados telescoping ), que no hacen nada más que llamarse unos a otros. Sin embargo, el habilitador de esta característica clara es pasar los argumentos por nombre .

La asociación nombrada es autodocumentada. Por el contrario, la asociación de argumentos posicionales es concisa, pero le obliga a consultar la definición de método todo el tiempo para verificar qué argumento se espera en la posición n en cada invocación. Esto es ridículo y nos motiva a buscar soluciones como el patrón Builder . El Builder realmente resuelve ambos problemas a la vez porque la asociación nombrada 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 Builder. Los fanáticos de los patrones pueden estar en desacuerdo, pero es una exageración crear una clase Builder para cada método con argumentos nombrados / opcionales. El diseño del lenguaje debe obviar este patrón estúpido. Pero, no sé qué tan compatibles son con la lista de argumentos variables.

Answer 2

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

Agregarlo ahora sería complicado, ya que debe hacerse de una manera compatible con versiones anteriores. Agregar varargs, autoboxing y genéricos en Java5 era una tarea importante, y solo se podía hacer con una funcionalidad limitada (como el borrado de tipo) y al costo de una mayor complejidad (las nuevas reglas de resolución de métodos hacen que las preguntas sean buenas).

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

Answer 3

No tengo conocimiento de una razón técnica, aparte de ser complicado qué valores se omiten y cuáles no.

Por ejemplo, en su muestra, si solo se pasó un entero, ¿es a o b que debe ser predeterminado? Probablemente a pero agrega ese nivel de ambigüedad.

Una solución simple sería

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

Sí, tiene un aliento más largo, y sí, oculta el valor predeterminado dentro del código, en lugar de la firma del método (que luego podría mostrarse en JavaDoc), pero hace cumplir la consistencia.

Answer 4

Para evitar la ambigüedad. Anulación del método de soporte de Java.

Asumimos el siguiente código:

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

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