Risposta.

Storia della domanda:

Le classi record (record) sono apparse in Java 14 come anteprima, dalla versione 16 di Java sono una funzionalità stabile. Implementano il concetto di contenitori immutabili (immutable) per la memorizzazione dei dati, simili agli oggetti valore. Questa è una risposta alla verbosità dei classici DTO e POJO in Java.

Problema:

Per oggetti semplici con dati, era necessario implementare manualmente costruttori, equals(), hashCode(), toString(). Questo è un lavoro routinario e soggetto a errori, che occupa molte righe di codice.

Soluzione:

Una classe record è dichiarata in una riga e ottiene automaticamente un costruttore, getter, equals(), hashCode(), toString(). I campi del record sono immutabili (final), i record sono particolarmente utili per il passaggio di informazioni tra i livelli dell'applicazione.

Esempio di codice:

public record Point(int x, int y) {}

Point p = new Point(3, 5);
System.out.println(p.x()); // 3
System.out.println(p); // Point[x=3, y=5]

Caratteristiche principali:

Immutabilità: campi final, valori impostati solo tramite il costruttore.
Generazione automatica dei metodi standard.
Non possono ereditare da altre classi (tranne Object); possono implementare interfacce.

Domande insidiose.

È possibile modificare lo stato di un oggetto record dopo la sua creazione?

No — tutti i campi sono final, non è possibile modificare il valore in alcun modo.

È possibile creare record con logica non standard nel costruttore?

Sì, è possibile definire un costruttore compatto o normale e aggiungere controlli:

public record Point(int x, int y) {
    public Point {
        if (x < 0 || y < 0) throw new IllegalArgumentException();
    }
}

Può un record essere astratto o ereditare campi/logica da altre classi?

No — il record è sempre final. Può implementare interfacce, ma non ereditare classi, tranne Object.

Errori comuni e anti-pattern

Tentativo di rendere i campi mutabili — la sintassi non lo permetterà.
Creazione di logica complessa all'interno del record, violando l'idea di semplici "contenitori di dati".
Uso di record dove è necessaria una classe normale con comportamento.

Esempio dalla vita reale

Caso negativo

Uso di lunghe POJO per ogni richiesta/risposta, con scrittura manuale di equals, hashCode, toString, costruttori e getter.

Pro:

Massima flessibilità di implementazione.

Contro:

Molto codice.
Alto rischio di errori.

Caso positivo

Traduzione di tutti i DTO in classi record:

public record UserDTO(String login, String email) {}