Me alegra que hayas descubierto la
Tupla, pero tu código tiene múltiples deficiencias si lo comparamos con las implementaciones estándar utilizadas en cualquier lenguaje actual.
1 - Para empezar, la única razón por la que estás escribiendo ese código es porque estás usando un lenguaje arcaico que se quedó atascado en 1999, ya que, a diferencia de prácticamente todos los demás lenguajes usados en la actualidad, java
no provee tuplas en su librería estandar. Mientras que cualquier lenguaje moderno y usable ya incorpora este concepto desde hace por lo menos una década.
Casi todos o directamente todos los demás lenguajes usados en la actualidad proveen esta característica "out of the box" (es decir, ya existe y no necesitas crearla vos mismo). Por supuesto java tiene 15 años de atraso con respecto a cualquier lenguaje moderno.
2 - Como java no posee
Value Types, o, estrictamente hablando, la capacidad de definir Value Types propios fuera de los que trae out-of-the-box (de nuevo, algo que los lenguajes modernos tienen hace 15 años), el valor de tu código se ve disminuído, ya que la Tupla es un caso típico para el uso de los mismos. al tratarse de un mero contenedor, el hecho de que sea
heap-allocated es realmente un desperdicio de memoria, e incrementa la presión del GC de forma innecesaria. Esta deficiencia no es salvable, al menos hasta que se implemente le soporte para value types en la JVM, que como viene va a estar para el 2020, básicamente 20 años más tarde que en en resto de los lenguajes usados en la actualidad.
3 - Otra deficiencia de java es la imposibilidad de definir tipos no nuleables. Es decir, cualquier referencia a tu clase siempre puede ser null y provocar excepciones. Esto no es salvable ni siquiera con el workaround que las últimas versiones de java introducen: un tipo Optional<T>, que por supuesto en sí mismo es nuleable como cualquier otra clase de java.
Esto en la práctica lleva a ensuciar el código con "programación defensiva", llenándo de if (x != null) por todos lados que solamente producen ruido inútil que por supuesto en lenguajes modernos es innecesario.
4 - Otro problema molesto de java es la carencia de
Properties, que también produce una cantidad de ruido completamente innecesario y cuya única razón de existir es la filosofía retrógrada noventosa de java.
En lugar de eso java te obliga a escribir esos getters y setters que son terriblemente tediosos, no solamente en su definición sino (y más importante) en el uso, ya que en lugar de usar la sintáxis miObjeto.Property se debe usar miObjeto.getProperty(), lo cuál es mucho más verboso y sucio.
Por supuesto todos los demás lenguajes tienen mejor soporte para este concepto que java, como demuestra el artículo.
5 - Siguiendo con las deficiencias de java, es importantísimo mencionar que los generics de java son terriblemente limitados y en realidad son un simple
"truco" del compilador, ya que no existen en runtime y la VM no tiene noción ni soporte para los mismos. En lugar de eso, todas tus referencias genéricas a tipos paramétricos se convierten en Object en tiempo de ejecución. Con lo cuál por ejemplo, para la JVM es imposible distinguir Dual<Cliente, Producto> de Dual<Perro, Gato> (por dar ejemplos simples).
Y esto no es lo peor de todo, sino que además de esta enorme deficiencia java presenta una aún peor: los generics de java NO soportan ni siquiera los value types predefinidos de java (conocidos como "tipos primitivos"), con lo cuál ni siquiera vas a poder crear un Dual<int, double> sino que vas a tener que usar los famosos "wrappers", desperdiciando todavía más memoria, y creando una indirección completamente innecesaria.
Alternativamente y como workaround, podes crear versiones especializadas no genéricas de tu clase para soportar los tipos primitivos: IntDual, DoubleDual, y asi. Por supuesto esta duplicación es terriblemente tediosa y acarrea una cantidad de problemas, por ejemplo el hecho de que IntDual sería completamente incompatible con DobleDual o Dual<Perro, Gato>.
6 - Otra carencia, o desición de diseño retrógrada de java es la negación a soportar
Sobrecarga de Operadores, con lo cuál para comparar dos instancias de tu clase se debe usar a.equals(b) en lugar de a == b que es muchísimo más limpio y claro, y que por supuesto es válido en todos los demás lenguajes excepto java. Esto sin mencionar que al ser una clase y no un Value Type o struct, no tiene identidad estructural y la tenés que implementar vos mismo overrideando equals(), getHashCode(), etc
Con todas estas deficiencias, podemos concluir sin temor a equivocarnos que claramente java es un pésimo lenguaje, y que en lugar de esperar otros 4 o 5 años a que se adapte y puedas sentir que al menos te moviste de 1999 a 2002, lo que más te conviene es utilizar cualquier lenguaje moderno y olvidarte de java para siempre, sepultándolo en el olvido donde corresponde, junto con Cobol y GW-Basic del año 70.
La "pura salud" es no tener que usar java jamás en la vida, para nada.
Ninguna de las deficiencias que menciono arriba existen en lenguajes modernos, como
Kotlin,
C#,
F#,
Python,
TypeScript, y cualquier otro lenguaje que no esté atascado en 1999 como java.
Te dejo un
ejemplo de tuplas implementadas en un lenguaje moderno, decente y usable.
Espero que te sirva. Saludos
