Lombok getter / setter vs Java 14 record

10

J'adore le projet Lombok mais ces jours-ci, je lis et j'essaie certaines des nouvelles fonctionnalités de java 14.

À l'intérieur de la nouvelle fonctionnalité, il y a le mot-clé record qui permet de créer une classe avec déjà intégré les fonctionnalités suivantes: constructeur, champs finaux privés, accesseurs, equals / hashCode, getters, méthodes toString.

Maintenant, ma question est la suivante: il vaut mieux s'appuyer sur la fonctionnalité de Lombok ou devrions-nous commencer à utiliser la fonctionnalité d'enregistrement:

Est préférable d'utiliser ceci:

record Person (String name, String surname) {}

ou ça:

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

Quels sont les avantages et les inconvénients de ces deux approches?

— gixlg
source

D'une part, recordne fonctionnera pas pour les choses qui attendent des getters et des setters de style JavaBeans.

— Mark Rotteveel

2

Ce que le commentaire de Rotteveel signifie, c'est que la méthode d'accesseur de propriété sur un enregistrement porte le même nom que la propriété. Ainsi, alice.phoneNumber()plutôt que la convention JavaBeans de préfixation avec get, comme dans alice.getPhoneNumber().

— Basil Bourque

1

La recordfonctionnalité est une fonctionnalité d'aperçu , pas encore prête à être utilisée en production.

— Basil Bourque

Les enregistrements ont beaucoup de restrictions par rapport aux classes, un enregistrement ne peut pas étendre un autre enregistrement ou une classe par exemple, consultez la section des restrictions de ce JEP openjdk.java.net/jeps/359 pour plus de détails

— NAIT

9

Lombok, et la recordfonctionnalité du langage Java, sont différents outils pour différentes choses. Il y a un chevauchement superficiel, mais ne laissez pas cela vous distraire.

Lombok est principalement une question de commodité syntaxique ; il s'agit d'un macro-processeur préchargé avec certains modèles de code utiles connus. Il ne confère aucune sémantique; il automatise simplement les motifs, selon certains boutons que vous définissez dans le code avec des annotations. Lombok est purement sur la commodité d'implémenter des classes porteuses de données.

Les enregistrements sont une caractéristique sémantique ; ce sont des tuples nominaux . En faisant une déclaration sémantique qui Point est un tuple de (int x, int y), le compilateur peut dériver sa représentation, ainsi que les protocoles de construction, de déclaration, d'égalité, de hachage et de représentation de chaîne, à partir de cette description d'état. Parce qu'ils portent la sémantique, les lecteurs et les frameworks peuvent également raisonner avec une plus grande confiance sur l'API des enregistrements. (Cela peut aussi être syntaxiquement pratique; si c'est le cas, c'est parfait.)

— Brian Goetz
source

1

+1 Brian Goetz: Et cela suppose que vous pouvez obtenir la version actuelle de Lombok dans votre IDE. Je me demande si Lombok a un avantage significatif en ce qui concerne la lecture de code plus rapide qu'un commentaire de classe ne conférerait pas.

— Trunk

4

Je joue avec cette combinaison depuis un certain temps également et avec le peu de pratique, je pourrais énumérer les différences suivantes:

Lombok

Les enregistrements ne sont pas encore une fonctionnalité publiée et ne sont qu'une fonctionnalité de prévisualisation. Rester avec Lombok est donc plus logique.
Ils ne sont pas encore un outil aussi puissant pour éliminer Lombok tous ensemble. Notez que la bibliothèque a bien plus à offrir que le seul @Getter, @AllArgsConstructor, @ToString, @EqualsAndHashCode.
Expérimenté par soi-même, le EqualsAndHashCoden'est pas le même que celui auquel vous vous attendez lorsqu'il s'agit de migrer vers des enregistrements .

Records

Sur une note différente, si l'exigence de votre représentation d'objet doit être un «support de données», vous pouvez toujours rechercher des avantages de Records, sans compter sur une bibliothèque supplémentaire pour réduire le code passe-partout pour effectuer cela avec précision. C'est la raison pour laquelle, comme note concluante, ce blog se lit comme suit:

Cela aidera également les équipes à éliminer de nombreuses implémentations codées à la main du modèle sous-jacent et à réduire ou supprimer le besoin de bibliothèques comme Lombok.

Bien sûr, au jour le jour, il est toujours sage, en fonction des exigences d'un projet, de choisir la voie à suivre et à pratiquer.

— Naman
source

Remarque - J'essaierais de garder cette mise à jour avec plus d'exemples pour être un utilisateur à utiliser les deux fréquemment à l'heure actuelle.

— Naman

3

NB: Au lieu de cet arbre de Noël d'annotations, vous pouvez simplement utiliser @Valuesur la classe. Notez que cela rend la classe finale, rend tous les champs à la fois privés et finaux, et vous donne également tout le reste. Ceci est proche de ce que sont les enregistrements (eux aussi sont définitifs et tous les champs à l'intérieur sont définitifs).

recordest toujours en avant-première, donc pour le code de production, ce n'est évidemment pas encore approprié. Utilisez lombok.

Une fois les enregistrements hors aperçu, c'est plus compliqué. Lombok est FAR plus flexible; vous pouvez facilement échanger un nouvel aspect sans avoir à réécrire tout le code (vous pouvez simplement, par exemple, ajouter une clause `` extend '' à votre classe sans avoir à écrire à la main la méthode equals et hashCode; quelque chose que les enregistrements ne peuvent pas vous donner). Lombok vous offre également plus de fonctionnalités: vous pouvez par exemple ajouter un générateur en ajoutant l' @Builderannotation; pas quelque chose que les enregistrements peuvent faire.

S'il est hautement improbable que vous utilisiez tout cela pour la classe que vous concevez - j'utiliserais des enregistrements.

AVERTISSEMENT: Je suis un contributeur principal au projet Lombok.

— rzwitserloot
source