java - example - Valor por defecto en lombok. Cómo iniciar por defecto con el constructor y el constructor

lombok java

Question

Tengo un objeto

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

Y lo inicializo de dos maneras.

UserInfo ui = new UserInfo();
UserInfo ui2 = UserInfo.builder().build();
System.out.println("ui: " + ui.isEmailConfirmed());
System.out.println("ui2: " + ui2.isEmailConfirmed());

Aquí está la salida

ui: true
ui2: false

Parece que el constructor no obtiene un valor predeterminado. Agrego la anotación @Builder.Default a mi propiedad y mi objeto ahora se ve así.

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

Aquí está la salida de la consola

ui: false
ui2: true

¿Cómo puedo hacer que ambos sean true ?

Answer 1

Mi conjetura es que no es posible (sin haber desactivado el código). Pero, ¿por qué no implementas el constructor que necesitas? Lombok está destinado a hacer su vida más fácil, y si algo no funciona con Lombok, simplemente hágalo a la antigua.

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

Salida de consola:

ui: true
ui2: true

Answer 2

Otra forma es definir su propio método getter anulando a 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 3

Ya que la github.com/rzwitserloot/lombok/issues/1347 , no la usaría en absoluto. Puede, sin embargo, utilizar el siguiente enfoque:

@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 esta manera te aseguras:

• el campo isEmailConfirmed se inicializa solo en un lugar, lo que hace que el código sea menos propenso a errores y más fácil de mantener más tarde
• la clase UserInfo se inicializará de la misma manera, ya sea que use un constructor o un constructor sin argumentos

En otras palabras, la condición es true :

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

En ese caso, la creación del objeto es coherente, no importa cómo lo cree. Es especialmente importante cuando su estructura es utilizada por un marco de mapeo o por un proveedor de JPA cuando no está creando instancias manualmente por un constructor, pero se invoca un constructor sin argumentos detrás de su espalda para crear la instancia.

El enfoque descrito anteriormente es muy similar pero tiene un gran inconveniente. Debe inicializar el campo en dos lugares, lo que hace que el código sea propenso a errores, ya que debe mantener los valores coherentes.