usar - Devuelve varios valores de un método Java: ¿por qué no se oponen n-tuples?

retornar un string en java

Question

¿Por qué no hay una solución (estándar, certificada por Java), como parte del lenguaje Java en sí, para devolver múltiples valores de un método Java, en lugar de que los desarrolladores tengan que usar sus propios medios, como mapas, listas, pares, etc. .? ¿Por qué Java no admite objetos n-tuple?

Especialmente pensando en métodos privados triviales que pueden modificar dos objetos juntos (en tándem), y en cuyo caso un objeto tipeado como resultado suena excesivo.

Answer 1

Hay muchas formas de hacer esto, una forma sería devolver un Object[] , pero luego tienes índices de los que preocuparte, y nulos controles de puntero, simplemente se pone desagradable. Otra forma es devolver un String , pero luego tienes que analizarlo, y se pone desagradable.

Creo que la verdadera pregunta es por qué?

Aquí está el problema: si estuviera trabajando en un proyecto con usted, y yo viera este tipo de comportamiento, lo reescribiría para que pueda ver cómo se debe manejar. Si proporciona un ejemplo de código, lo reescribiré para ilustrarlo.

Escriba sus métodos con una sola responsabilidad, si necesitan devolver más datos de los que tienen la capacidad de hacerlo, es probable que use un objeto o lo divida en métodos más pequeños.

Answer 2

Hay un nuevo estilo de patrón disponible que encaja con la naturaleza "totalmente asincrónica" que puede ver en idiomas como JavaScript.

Gran parte de mi código se ve así hoy en día :-)

public class Class1 {
public interface Callback {
void setData(String item1, String item2);
}
public void getThing(Callback callback) {
callback.setData("a", "b");
}
}
public class Class2 {
public void doWithThing(Class1 o) {
o.getThing(new Class1.Callback() {
public void setData(String item1, String item2) {
... do something with item 1 and item 2 ...
}
});
}
}

No hay objetos nuevos para crear y no muchas clases adicionales, ya que la interfaz es una clase interna del objeto.

Esto es lo que hace que Swift sea tan increíble. El código puede verse así:

o.getThing({ item1, item2 -> Void in
... do something with item 1 and item 2 ...
});

Y dado que el único argumento es el bloque, incluso esto:

o.getThing { item1, item2 -> Void in
... do something with item 1 and item 2 ...
};

Java necesita trabajo para hacer que el código cargado de devolución de llamada sea mucho más fácil de leer.

Answer 3

Los métodos Java devuelven exactamente cero o un valor; ese es el estándar para java. Si necesita que se devuelvan valores múltiples, cree un objeto con los valores múltiples y devuélvalo.

Answer 4

Porque devolver el valor múltiple de un método no es una práctica recomendada (en Java).

Si necesita valores no relacionados de un método, necesita una estructura de datos diferente, como un objeto que contenga esos valores. Si necesita varias instancias de la misma clase (es decir, varias cadenas), debe devolver una matriz o una colección, según sus necesidades.

La devolución de valores múltiples en otros idiomas (por ejemplo, Go) se usa para devolver un código de eror, pero Java se diseñó de manera diferente utilizando excepciones.

Answer 5

Si desea devolver dos objetos, generalmente desea devolver un único objeto que encapsula los dos objetos.

Answer 6

Supongo que el OP significa "¿Por qué Java no admite objetos n-tuple?". Python, Haskell, Lisp, ML etc. tienen capacidades heterogéneas de n-tupla. También muchas veces la capacidad de devolver aparentemente múltiples objetos en un idioma es azúcar sintáctica (es decir, en python return ''a'', ''b'').

La razón, por supuesto, es el diseño del lenguaje y la consistencia. Java prefiere ser muy explícito y no le gustan las estructuras de datos anónimas (aunque me gustaría tener cierres anónimos).

Por ejemplo, en Java no hay forma de decir que me gustaría una devolución de llamada que tome estos parámetros de tipo y lo devuelva. Algunas personas sienten que esto es una debilidad enorme, a otros les gusta la consistencia y la claridad.

En mi humilde opinión, aunque es molesto, con frecuencia combato este problema haciendo clases en línea estáticas:

private static class Combo {
String name;
int weight;
}

Sí, es tedioso, pero luego, con frecuencia, reutilizo y refactorizo ​​esas clases, lo que las convierte en un nivel superior y agrega comportamiento. De hecho, una de las ventajas de seguir esta ruta es que es mucho más fácil agregar nuevos campos donde está la estructura de datos anónimos (como en los lenguajes FP) se vuelve mucho más difícil agregar un campo (terminas cambiando una tonelada de código).

Debo señalar que para 2-tuplas algunas personas usan (o abusan) java.util.Map.Entry ya que hay una java.util.AbstractMap.SimpleEntry en Java 6. También algunas personas ahora usan el soporte de Commons Lang3''s Pair (2-tuple) )

Scala tiene soporte n-tuple por tipo de trampa y tiene un conjunto completo de 2-16 interfaces de tupla que son estándar en el lenguaje y están sintácticamente ocultas para el programador.

Por razones puramente educativas, es posible que desee ver cómo otros idiomas logran esto .

ACTUALIZACIÓN: para Java 8

Java 8 will / maybe (así que aquí está mi número ... llámeme tal vez) admite una interfaz llamada java.lang.BiValue con una implementación concreta que puede usar llamada java.lang.BiVal . Estas clases son para ayudar a respaldar la nueva funcionalidad lambda. Pero note que esto es solo para 2-tuplas.

ACTUALIZACIÓN: para 2015

Java 8 no obtuvo soporte para tuplas.

ACTUALIZACIÓN: del autor 2015

Si aún desea el soporte de tuplas, existen tres bibliotecas que admiten bien las tuplas:

• javatuples : admite JDK 5 y superior. Hasta 10 tuplas
• JOOλ - Del autor de jOOQ pero requiere JDK 8.
• Commons Lang 3 - Ahora admite un Triple (3-tuple) y es compatible con JDK 6 y superior.