Valeur par défaut à lombok. Comment initier la valeur par défaut avec le constructeur et le builder ?

Question

J'ai un objet

@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class UserInfo {
    private int id;
    private String nick;
    private boolean isEmailConfirmed = true;
}

Et je l'initialise de deux façons

UserInfo ui = new UserInfo();
UserInfo ui2 = UserInfo.builder().build();

System.out.println("ui: " + ui.isEmailConfirmed());
System.out.println("ui2: " + ui2.isEmailConfirmed());

Voici le résultat

ui: true
ui2: false

Il semble que le constructeur n'obtienne pas de valeur par défaut. J'ajoute @Builder.Default à ma propriété et mon objet ressemble maintenant à ceci

@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class UserInfo { 
    private int id;
    private String nick;
    @Builder.Default
    private boolean isEmailConfirmed = true;
}

Voici la sortie de la console

ui: false
ui2: true

Comment puis-je faire en sorte que les deux soient true ?

Answer 1

A mon avis, ce n'est pas possible (sans avoir décomposé le code). Mais pourquoi n'implémentez-vous pas simplement le constructeur dont vous avez besoin ? Lombok est censé vous faciliter la vie, et si quelque chose ne fonctionne pas avec Lombok, faites-le simplement à l'ancienne.

@Data
@Builder
@AllArgsConstructor
public class UserInfo { 
    private int id;
    private String nick;
    @Builder.Default
    private boolean isEmailConfirmed = true;

    public UserInfo(){
        isEmailConfirmed = true;
    }
}

Sortie de console :

ui: true
ui2: true

Mise à jour
A partir de 01/2021, ce bug semble être corrigé à Lombok au moins pour les constructeurs générés. Notez qu'il y a toujours une question similaire quand vous mélangez Builder.Default et des constructeurs explicites.

Answer 2

Depuis le @Builder.Default l'annotation est brisée je ne l'utiliserais pas du tout. Vous pouvez toutefois utiliser l'approche suivante en déplaçant l'élément @Builder du niveau de la classe au constructeur personnalisé :

@Data
@NoArgsConstructor
public class UserInfo {

    private int id;
    private String nick;
    private boolean isEmailConfirmed = true;

    @Builder
    @SuppressWarnings("unused")
    private UserInfo(int id, String nick, Boolean isEmailConfirmed) {
        this.id = id;
        this.nick = nick;
        this.isEmailConfirmed = Optional.ofNullable(isEmailConfirmed).orElse(this.isEmailConfirmed);
    }
}

De cette façon, vous vous assurez :

• le champ isEmailConfirmed est initialisé à un seul endroit, ce qui rend le code moins sujet aux erreurs et plus facile à maintenir par la suite.
• le site UserInfo sera initialisée de la même manière, que vous utilisiez un constructeur ou un constructeur sans argument.

En d'autres termes, la condition est la suivante true :

new UserInfo().equals(UserInfo.builder().build())

Dans ce cas, la création de l'objet est cohérente, quelle que soit la façon dont vous le créez. C'est particulièrement important lorsque votre classe est utilisée par un framework de mapping ou par un fournisseur JPA et que vous ne l'instanciez pas manuellement par un builder mais qu'un constructeur no-args est invoqué derrière votre dos pour créer l'instance.

L'approche décrit ci-dessus est très similaire mais présente un inconvénient majeur. Vous devez initialiser le champ à deux endroits, ce qui rend le code sujet aux erreurs car vous êtes tenu de conserver des valeurs cohérentes.

Answer 3

Une autre façon est de définir votre propre getter méthode Remplacement de el lombok getter :

@Data
@Builder
@AllArgsConstructor
public class UserInfo { 
    private int id;
    private String nick;
    private Boolean isEmailConfirmed;

    public Boolean getIsEmailConfirmed(){
      return Objects.isNull(isEmailConfirmed) ? true : isEmailConfirmed;
    }
}

Answer 4

Voici mon approche :

@Data
@NoArgsConstructor
@AllArgsConstructor
@Builder(toBuilder = true)
public class UserInfo { 
    private int id;
    private String nick;
    private boolean isEmailConfirmed = true;
}

Et puis

UserInfo ui = new UserInfo().toBuilder().build();

Answer 5

Constructeurs personnalisés et @Builder.Default ne travailleront probablement jamais ensemble.

Les auteurs du cadre veulent éviter les initialisations doubles pour @Builder .

Je réutilise .builder() por public static CLAZZ of(...) méthodes :

@Builder
public class Connection {
    private String user;
    private String pass;

    @Builder.Default
    private long timeout = 10_000;

    @Builder.Default
    private String port = "8080";

    public static Connection of(String user, String pass) {
        return Connection.builder()
            .user(user)
            .pass(pass)
            .build();
    }

    public static Connection of(String user, String pass, String port) {
        return Connection.builder()
            .user(user)
            .pass(pass)
            .port(port)
            .build();
    }

    public static Connection of(String user, String pass, String port, long timeout) {
        return Connection.builder()
            .user(user)
            .pass(pass)
            .port(port)
            .timeout(timeout)
            .build();
    }
}

Vérifiez la discussion correspondante : https://github.com/rzwitserloot/lombok/issues/1347