Antwoord.

Geschiedenis van de vraag:

Record-klassen (record) kwamen voor het eerst voor in Java 14 als preview, en vanaf de release van Java 16 is het een stabiele functie. Ze implementeren het concept van onveranderlijke (immutable) containers voor het opslaan van gegevens, vergelijkbaar met value-objects. Dit was een reactie op de omslachtigheid van klassieke DTO- en POJO-structuren in Java.

Probleem:

Voor eenvoudige data-objecten moest men handmatig de constructeurs, equals(), hashCode(), toString() implementeren. Dit is een routinematige, foutgevoelige taak die veel regels code vereist.

Oplossing:

Een record-klasse wordt in één regel gedeclareerd en ontvangt automatisch de constructeur, getters, equals(), hashCode(), toString(). De velden van een record zijn onveranderlijk (final), en record-structuren zijn vooral nuttig voor het doorgeven van informatie tussen de lagen van een applicatie.

Voorbeeldcode:

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]

Belangrijkste kenmerken:

Onveranderlijkheid: velden zijn final, waarden worden alleen via de constructeur ingesteld.
Automatische generatie van standaardmethoden.
Kunnen niet erven van andere klassen (behalve Object); kunnen interfaces implementeren.

Vragen met een valstrik.

Kan de toestand van een record-object na de creatie worden gewijzigd?

Nee — alle velden zijn final, de waarde kan op geen enkele manier worden gewijzigd.

Kan je een record maken met niet-standaard logica in de constructeur?

Ja, je kunt een compacte of gewone constructeur definiëren en controles toevoegen:

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

Kan een record abstract zijn of velden/logica van andere klassen erven?

Nee — een record is altijd final. Het kan interfaces implementeren, maar geen klassen erven, behalve Object.

Typische fouten en anti-patronen

Poging om velden vervormbaar te maken — de syntax staat dit niet toe.
Het creëren van complexe logica binnen een record, wat het idee van eenvoudige "gegevenscontainers" schendt.
Het gebruik van records waar een gewone klasse met gedrag nodig is.

Voorbeeld uit het leven

Negatieve casus

Gebruik van lange POJO's voor elke aanvraag/antwoord, met handmatige implementatie van equals, hashCode, toString, constructeurs en getters.

Voordelen:

Volledige implementatie flexibiliteit.

Nadelen:

Veel code.
Hoge kans op fouten.

Positieve casus

Omzetting van alle DTO's naar record-klassen:

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