Lombok getter / setter vs Java 14 record

10

Me encanta el proyecto Lombok pero en estos días estoy leyendo y probando algunas de las nuevas características de Java 14.

Dentro de la nueva capacidad, existe la palabra clave record que permite crear una clase con la siguiente funcionalidad incorporada: constructor, campos finales privados, accesores, equals / hashCode, getters, toString.

Ahora mi pregunta es: es mejor confiar en la función de Lombok o deberíamos comenzar a usar la funcionalidad de registro:

Es mejor usar esto:

record Person (String name, String surname) {}

o eso:

@AllArgsConstructor
@ToString
@EqualsAndHashCode
public class GetterSetterExample {
  @Getter private int name;
  @Getter private int surname;
}

¿Cuáles son los pros y los contras de ambos enfoques?

gixlg
fuente
Por un lado, recordno funcionará para las cosas que esperan getters y setters de estilo JavaBeans.
Mark Rotteveel
2
Lo que significa el comentario de Rotteveel es que el método de acceso a la propiedad en un registro se llama con el mismo nombre de la propiedad. Entonces, en alice.phoneNumber()lugar de la convención JavaBeans de prefijar con get, como en alice.getPhoneNumber().
Basil Bourque
1
La recordfunción es una función de vista previa , aún no está lista para su uso en producción.
Basil Bourque
Los registros tienen muchas restricciones en comparación con las clases, un registro no puede extender otro registro o clase, por ejemplo, consulte la sección de restricciones en este JEP openjdk.java.net/jeps/359 para más detalles
NAIT

Respuestas:

9

Lombok y el record característica del lenguaje Java, son diferentes herramientas para diferentes cosas. Hay una superposición superficial, pero no dejes que eso te distraiga.

Lombok se trata principalmente de conveniencia sintáctica ; Es un macroprocesador precargado con algunos patrones de código útiles conocidos. No confiere ninguna semántica; solo automatiza los patrones, de acuerdo con algunas perillas que configuró en el código con anotaciones. Lombok es puramente sobre la conveniencia de implementar clases portadoras de datos.

Los registros son una característica semántica ; Son tuplas nominales . Al hacer una declaración semántica que Point es una tupla de (int x, int y), el compilador puede derivar su representación, así como los protocolos de construcción, declaración, igualdad, hash y representación de cadenas, a partir de esta descripción de estado. Debido a que tienen semántica, los lectores y los marcos también pueden razonar con mayor confianza sobre la API de los registros. (Esto también puede ser sintácticamente conveniente; si es así, eso es genial).

Brian Goetz
fuente
1
+1 Brian Goetz: Y eso supone que puedes obtener la versión actual de Lombok en tu IDE. Me pregunto si Lombok tiene alguna ventaja significativa con respecto a la lectura más rápida del código que un comentario de clase no conferiría.
Tronco
4

He estado jugando con esta combinación durante algún tiempo también y con un poco de práctica podría enumerar las siguientes diferencias:

Lombok

  • Los registros aún no son una función lanzada y son solo una función de vista previa. Así que quedarse con Lombok tiene más sentido.
  • Todavía no son una herramienta tan poderosa para eliminar a Lombok por completo. Tenga en cuenta que la biblioteca tiene mucho más que ofrecer que solo el @Getter, @AllArgsConstructor, @ToString, @EqualsAndHashCode.
  • Experimentado por EqualsAndHashCodeusted mismo, no es lo mismo que esperaría cuando se trata de migrar a registros .

Registros

  • En una nota diferente, si el requisito de su representación de objeto es ser un "soporte de datos", aún puede buscar la ventaja de los Registros, sin depender de una biblioteca adicional para reducir el código repetitivo para realizar eso con precisión. Esa es la razón por la que, como nota concluyente, este blog lee lo siguiente:

    También ayudará a los equipos a eliminar muchas implementaciones codificadas a mano del patrón subyacente y reducir o eliminar la necesidad de bibliotecas como Lombok.

Por supuesto, en el día a día, siempre es sabio basarse en los requisitos de un proyecto para elegir qué camino seguir y practicar.

Naman
fuente
Nota: trataría de mantener esto actualizado con más ejemplos para ser un usuario que los use con frecuencia en la actualidad.
Naman
3

NB: en lugar de ese árbol de Navidad de anotaciones, puedes usarlo @Valueen la clase. Tenga en cuenta que esto hace que la clase sea final, y hace que todos los campos sean privados y finales, y también le brinda todo el resto. Esto está cerca de lo que son los registros (ellos también son finales, y todos los campos dentro son finales).

recordtodavía está en la vista previa, por lo que para el código de producción, obviamente, aún no es adecuado. Usa lombok.

Una vez que los registros están fuera de la vista previa, es más complicado. Lombok es MUCHO más flexible; puede cambiar fácilmente algún aspecto nuevo sin tener que reescribir todo el código (puede simplemente, por ejemplo, agregar una cláusula 'extend' a su clase sin tener que escribir a mano el método igual y hashCode; algo que los registros no pueden proporcionarle). Lombok también le ofrece más funciones: por ejemplo, puede agregar un generador agregando la @Builderanotación; No es algo que los registros puedan hacer.

Si es muy poco probable que vayas a usar algo de eso para la clase que estás diseñando, usaría registros.

DESCARGO DE RESPONSABILIDAD: Soy un contribuidor principal del Proyecto Lombok.

rzwitserloot
fuente