Records vs Clases vs Lombok vs Kotlin vs Scala

¿Cuál es la mejor forma de modelar datos? Desde los Struct de c++ nos venimos preguntando esto. Vamos a ver algunas opciones modernas que nos provee la plataforma java. 

Cuando trabajamos con objetos que representan datos (DTOs, Value Objects, etc.), distintos lenguajes ofrecen soluciones para evitar el boilerplate.

En este post comparamos:

• Records en Java
• Clases tradicionales
• Lombok
• Data classes en Kotlin
• Case classes en Scala

1. Clase tradicional (Java)

public class Persona {

    private final String nombre;

    private final int edad;

    public Persona(String nombre, int edad) {

        this.nombre = nombre;

        this.edad = edad;

    }

    public String getNombre() { return nombre; }

    public int getEdad() { return edad; }

    @Override public boolean equals(Object o) { ... }

    @Override public int hashCode() { ... }

    @Override public String toString() { ... }

}

Ventajas

• Total control
• Compatible con todo (JPA, frameworks)

Desventajas

• Mucho boilerplate
• Propenso a errores

2. Records (Java)

public record Persona(String nombre, int edad) {}

Ventajas

• Ultra conciso
• Inmutabilidad garantizada
• Sin dependencias

Desventajas

• Menos flexible
• No sirve bien con JPA
• No herencia

3. Lombok (@Data)

import lombok.Data;

@Data

public class Persona {

    private String nombre;

    private int edad;

}

Ventajas

• Reduce mucho código
• Mutable o inmutable (configurable)

Desventajas

• Dependencia externa
• "Magia" en compilación (puede confundir)
•  Problemas en tooling/debug

4. Data Classes (Kotlin)

data class Persona(val nombre: String, val edad: Int)

Ventajas

• Muy conciso
• Inmutable por defecto
• copy() incluido
• Destructuring

val (nombre, edad) = persona

Desventajas

• Requiere usar Kotlin
• Interoperabilidad Java no siempre perfecta

5. Case Classes (Scala)

case class Persona(nombre: String, edad: Int)

Ventajas

• Inmutables
• Pattern matching nativo
• copy() automático
• Muy expresivas

persona match {

  case Persona(nombre, edad) => println(nombre)

}

Desventajas

• Curva de aprendizaje
• Ecosistema más complejo

Y entonces? Y ninguno es super mejor, pero podemos tener estas reglas: 

Java Records

Ideal para:

• DTOs simples
• APIs REST
• Código moderno sin dependencias

Son el "mínimo viable elegante" en Java.

Lombok

Ideal para:

• Proyectos legacy
• Equipos que ya lo usan

 Soluciona el problema… pero no es parte del lenguaje.

Kotlin

La mejor experiencia general para modelado de datos.

• copy()
• destructuring
• null-safety

Es claramente superior en ergonomía.

Scala

El más poderoso conceptualmente.

• Pattern matching real
• Inmutabilidad fuerte
• Integración con FP

Pero más complejo.

 Clases Java

 Siguen siendo necesarias cuando:

• Usás JPA
• Necesitás mutabilidad
• Requerís control total

Si estás en Java moderno → Records

Si querés máxima productividad → Kotlin

Si buscás poder expresivo → Scala

Si estás en legacy → Lombok o clases

Lombok @Builder: Simplificando la Creación de Objetos en Java

En el blog nunca he hablado de lombok, porque no me gusta que exista un framework que haga lo que tendria que tener el lenguaje que programamos. Pero esta funcionalidad de lombok no la conocia y me esta buena. 

La creación de objetos con múltiples atributos puede volverse tediosa y propensa a errores si se usa el enfoque tradicional de constructores o setters. Lombok ofrece la anotación @Builder, que es una solución elegante que permite generar automáticamente un patrón de construcción de objetos de manera fluida y legible.

Lombok es una librería que reduce el código repetitivo en Java mediante anotaciones que generan automáticamente métodos como getter, setter, equals, hashCode y toString. Una de sus anotaciones más útiles es @Builder, que facilita la creación de objetos sin necesidad de escribir constructores manualmente.

Para agregar Lombok, si usas Maven, agrega la siguiente dependencia:

<dependency>

    <groupId>org.projectlombok</groupId>

    <artifactId>lombok</artifactId>

    <version>1.18.26</version>

    <scope>provided</scope>

</dependency>

Si usas Gradle:

dependencies {

    compileOnly 'org.projectlombok:lombok:1.18.26'

    annotationProcessor 'org.projectlombok:lombok:1.18.26'

}

Veamos un ejemplo de una clase que tiene un builder: 

import lombok.Builder;

import lombok.Getter;

import lombok.ToString;

@Getter

@ToString

@Builder

public class Usuario {

    private String nombre;

    private String email;

    private int edad;

}

public class Main {

    public static void main(String[] args) {

        Usuario usuario = Usuario.builder()

                .nombre("Juan Pérez")

                .email("juan.perez@example.com")

                .edad(30)

                .build();

        

        System.out.println(usuario);

    }

}

Se puede personalizar el constructor y el nombre del método de construcción con @Builder, veamos un ejemplo :

@Builder(builderMethodName = "nuevoUsuario")

public class Usuario {

    private String nombre;

    private String email;

    private int edad;

}

Uso:

Usuario usuario = Usuario.nuevoUsuario()

        .nombre("Ana López")

        .email("ana.lopez@example.com")

        .edad(28)

        .build();

El uso de @Builder en Lombok simplifica la creación de objetos en Java, haciendo que el código sea más conciso, flexible y fácil de mantener. Esta anotación es especialmente útil cuando se manejan objetos con múltiples atributos opcionales, evitando la necesidad de escribir múltiples constructores sobrecargados.

Dejo link:

https://www.baeldung.com/lombok-builder