Records

Records

0:00 Willkommen zum ersten Modul unseres Deep Dive in die fortgeschrittenen Sprachmittel von Java. Wir beginnen mit einem Thema, das auf den ersten Blick klein wirkt und im Alltag trotzdem erstaunlich viel bewegt: Records. Fast jede Anwendung, die Sie schreiben, verschiebt Daten von A nach B — aus einer Datenbank in ein Objekt, aus einem Objekt in eine Schnittstelle.

0:20 Für diese Datencontainer haben Java-Entwickler jahrzehntelang immer wieder denselben Code getippt. Seit Java sechzehn gibt es dafür ein eigenes Sprachmittel. In den nächsten Kapiteln sehen wir uns an, was Records genau sind, wo ihre Grenzen liegen und an welcher Stelle Sie trotzdem selbst Hand anlegen müssen.

Records

0:38 Der erste Tag beginnt bei den Daten. Das ist kein Zufall: Bevor Sie Verhalten modellieren können, brauchen Sie saubere Datentypen. Wir schauen uns zuerst an, wie eine klassische Datenklasse aussieht und was ein Record davon übrig lässt. Danach geht es um Konstruktoren — um das Prüfen von Argumenten und um eine Falle, die viele erst spät bemerken.

0:58 Zum Schluss klären wir, welche Methoden der Compiler für Sie erzeugt und wo Ihre eigenen hingehören. Als durchgehendes Beispiel begleitet uns Lagerpuls, eine kleine Lagerverwaltung, die über alle neun Module mitwächst. Vier Fragen strukturieren dieses Modul. Die erste ist eine Entwurfsfrage: Warum ist es überhaupt ein Vorteil, wenn sich ein Objekt nach dem Erzeugen nicht mehr ändern lässt?

1:21 Die zweite ist handwerklich: Was genau macht der Compiler aus so einer Komponentenliste? Die dritte ist die praktisch wichtigste — Records sind nämlich nicht ganz so unveränderlich, wie viele annehmen, und genau dort entstehen Fehler. Und die vierte Frage ist die nach der Grenze: Was darf in einen Record hinein, was gehört woandershin?

1:40 Behalten Sie besonders den dritten Punkt im Kopf, er wird uns noch beschäftigen.

Datencontainer als Record schreiben

1:45 Fangen wir dort an, wo der Alltag anfängt: bei einer ganz normalen Klasse, die nichts weiter tut, als ein paar Werte zusammenzuhalten. Sie kennen solche Klassen aus jedem Projekt — Kunde, Bestellung, Konfigurationseintrag. Und Sie kennen wahrscheinlich auch das Gefühl beim Schreiben, immer wieder dasselbe zu tippen. Genau dieses Gefühl war der Anlass für Records.

2:07 Sehen wir uns also zuerst an, wie so eine Klasse von Hand aussieht, und danach, was davon übrig bleibt, wenn man sie dem Compiler überlässt. Ein Record ist im Kern eine Abkürzung — aber eine, die der Compiler versteht. Stellen Sie sich ein Formular vor: Sie tragen oben ein, welche Felder es gibt, und alles andere — Nummerierung, Kopfzeile, Unterschriftenfeld — kommt automatisch dazu.

2:30 Genau so funktioniert ein Record. Sie schreiben die Komponentenliste in Klammern hinter den Namen, und der Compiler erzeugt daraus die Felder, den Konstruktor, die Zugriffsmethoden und die drei Klassiker equals, hashCode und toString. Wichtig ist die Einordnung: Ein Record ist kein Sonderkonstrukt neben den Klassen, sondern eine besondere Art von Klasse.

2:51 Das erklärt später, warum vieles funktioniert, was Sie von Klassen gewohnt sind. Sehen wir uns an, wovon wir uns verabschieden. Hier steht ein Artikel aus unserem Lagerpuls-Beispiel als klassische Klasse. Interessant sind an diesem Code genau zwei Zeilen — die beiden Felder. Alles andere ist Zeremonie: ein Konstruktor, der die Felder befüllt, für jedes Feld eine Zugriffsmethode, dazu equals, hashCode und toString.

3:16 Der Kommentar am Ende verschweigt noch die längste Strecke. In Summe schreiben Sie für zwei Informationen leicht dreißig Zeilen. Und jede dieser Zeilen kann einen Fehler enthalten, den niemand mehr liest, weil sie alle gleich aussehen. Das ist der eigentliche Punkt: Nicht die Tipparbeit ist teuer, sondern die Aufmerksamkeit, die sie bindet.

3:37 Und das ist dieselbe Klasse als Record. Eine Zeile. Der Rumpf darf sogar leer bleiben. Was hier passiert, ist bemerkenswert: Sie haben nicht weniger Funktionalität als vorher, sondern exakt dieselbe — nur schreibt sie jetzt der Compiler. Achten Sie auf den Wechsel im Schlüsselwort: statt class steht dort record, und die Felder wandern in Klammern hinter den Namen.

3:58 Für Ihren Alltag heißt das vor allem eines: Eine Änderung am Datenmodell ist jetzt eine Ein-Zeilen-Änderung. Sie müssen nicht mehr daran denken, equals nachzuziehen, wenn ein Feld dazukommt. Genau dieses Vergessen war früher eine der häufigsten Fehlerquellen. Diese Übersicht ist weniger eine Liste zum Auswendiglernen als eine Antwort auf die Frage „Was passiert da eigentlich?".

4:21 Der rote Faden dahinter: Der Compiler erzeugt genau das, was sich aus der Komponentenliste zwingend ergibt — und nichts darüber hinaus. Die Felder sind privat und final, weil ein Record unveränderlich sein soll. Die Zugriffsmethoden heißen wie die Komponenten, ohne get davor; das ist gewöhnungsbedürftig, aber konsequent, denn eine Komponente ist kein Feld mit Getter, sondern schlicht ein benannter Wert.

4:45 Und equals, hashCode und toString beziehen immer alle Komponenten ein. Überschreiben dürfen Sie das alles — nötig ist es fast nie. Jetzt die Frage, die hinter dem ganzen Konzept steht: Warum ist Unveränderlichkeit überhaupt erstrebenswert? Der praktische Gewinn zeigt sich beim Debuggen. Wenn ein Objekt sich nicht ändern kann, entfällt die ganze Klasse von Fragen, die sonst am meisten Zeit kostet — wer hat diesen Wert wann überschrieben?

5:10 Daraus folgt der Rest fast von selbst: Sie können solche Objekte gefahrlos weiterreichen, zwischenspeichern und über Threads hinweg teilen, ohne Schutzkopien anzulegen. Und ein Detail, das oft unterschätzt wird: HashMap und HashSet setzen darauf, dass sich der hashCode eines Schlüssels nicht ändert. Veränderliche Schlüssel sind eine der unangenehmsten Fehlerquellen überhaupt.

5:32 Zeit, das selbst auszuprobieren. Die Aufgabe klingt simpel — eine Datenklasse in einen Record überführen —, aber der eigentliche Lerneffekt liegt woanders. Sie werden beim Zurückführen merken, welche Teile Ihrer alten Klasse wirklich Daten waren und welche sich unterwegs eingeschlichen haben. Genau diese Trennung ist die Fähigkeit, die wir hier üben.

5:52 Erkennen können Sie den Erfolg an einer Kleinigkeit: Ein Aufruf von toString gibt alle Komponenten mit Werten aus, ohne dass Sie eine Zeile dafür geschrieben haben. Und wenn Sie dann eine dritte Komponente ergänzen, wächst die Ausgabe von allein mit. Vier Dinge gehen erfahrungsgemäß schief. Der erste Punkt ist reine Gewohnheit: Wer zwanzig Jahre getName geschrieben hat, tippt es auch im Record — und wundert sich, dass nichts zusammenpasst.

6:17 Der zweite ist eine echte Einschränkung: Zusätzliche Instanzfelder sind im Record verboten, weil die Komponentenfelder die einzige Wahrheit sein sollen. Der dritte Punkt ist eine Erwartungsfrage — wer Setter sucht, hat den Zweck des Konstrukts noch nicht angenommen. Und der vierte ist der wichtigste: Ein Record ist nicht automatisch tief unveränderlich. Warum das so ist und was Sie dagegen tun, sehen wir uns gleich im nächsten Kapitel an.

Konstruktoren von Records definieren

6:43 Damit sind wir beim Konstruktor. Auf den ersten Blick ein langweiliges Thema — der Compiler erzeugt ihn ja ohnehin, und die meisten Records kommen ohne einen eigenen aus. Auf den zweiten Blick ist es die Stelle, an der Sie entscheiden, ob Ihr Datentyp seine Zusagen tatsächlich einhält. Es gibt genau zwei Gründe, hier selbst einzugreifen.

7:03 Einer davon ist gut bekannt und wird oft genutzt. Der andere wird regelmäßig übersehen — und genau er entscheidet darüber, ob Ihr Record wirklich unveränderlich ist. Der Konstruktor, dessen Parameter genau der Komponentenliste entsprechen, hat einen eigenen Namen: der kanonische Konstruktor. Merken Sie sich den Begriff, er taucht in Fehlermeldungen auf.

7:24 Normalerweise erzeugt ihn der Compiler, aber Sie dürfen ihn auch selbst schreiben — im Rumpf des Records, ganz so wie in einer gewöhnlichen Klasse. Das ist die praktische Konsequenz aus dem, was wir vorhin gesagt haben: Ein Record ist eine Klasse. Alles, was Sie über Konstruktoren wissen, gilt weiter. Es kommen nur ein paar Regeln dazu, die dafür sorgen, dass der Record schlank bleibt.

7:48 Es gibt genau zwei gute Gründe, den Konstruktor selbst zu schreiben. Der erste ist das Prüfen: Ein Artikel ohne Nummer ist fachlich sinnlos, also soll er gar nicht erst entstehen können. Das ist ein wichtiger Gedanke — nicht später prüfen, ob ein Objekt gültig ist, sondern ungültige Objekte unmöglich machen. Der zweite Grund ist die defensive Kopie, und der ist subtiler; dazu kommen wir gleich. Alles andere gehört ausdrücklich nicht in den Konstruktor.

8:16 Umrechnen, Formatieren, Ableiten — das sind Methoden. Ein Konstruktor, der rechnet, ist fast immer ein Zeichen dafür, dass der Typ zu viel tut. Hier sehen Sie die ausgeschriebene Variante. Der Aufbau ist vertraut: Parameter entgegennehmen, prüfen, den Feldern zuweisen. Und genau daran sieht man das Problem. Die Parameterliste wiederholt Wort für Wort die Komponentenliste, und die Zuweisungen am Ende sind exakt der Rumpfcode, den Records eigentlich abschaffen sollten.

8:44 Inhaltlich interessant sind nur die zwei Zeilen mit der Prüfung. Halten Sie das im Hinterkopf — Java hat für dieses Ärgernis eine eigene Schreibweise, die wir uns im nächsten Kapitel ansehen. Fürs Erste zählt: Prüfen im Konstruktor ist erlaubt, üblich und richtig. Und jetzt zu der Sache, die viele überrascht. Records sind nur flach unveränderlich. Das Bild dazu: Stellen Sie sich ein Schließfach vor, dessen Schlüssel Sie einbetoniert haben.

9:11 Das Fach lässt sich nicht mehr austauschen — aber wenn Sie den Inhalt vorher jemand anderem in die Hand gegeben haben, kann der weiterhin Dinge hineinlegen. Genau so verhält sich eine Komponente vom Typ ArrayList. Die Referenz steht fest, der Inhalt nicht. Der Record verspricht also Unveränderlichkeit auf einer Ebene, die für Sammlungen und andere veränderliche Typen nicht ausreicht.

9:34 Diese drei Zeilen zeigen den Effekt in Reinform. Der Aufrufer legt eine Liste an, gibt sie in den Record hinein — und behält seine eigene Referenz darauf. Ein einziger Aufruf später steht in unserem angeblich unveränderlichen Artikel ein Eintrag, den niemand dort hineingeschrieben hat. Was diesen Fehler so unangenehm macht, ist nicht die Mechanik, sondern der Zeitversatz.

9:55 In echtem Code liegen zwischen dem Hineingeben und dem nachträglichen Ändern oft ganze Schichten. Wenn der Fehler auffällt, sucht man an der falschen Stelle. Deshalb ist die Gegenmaßnahme keine Kür, sondern Pflicht. Die Gegenmaßnahme heißt defensive Kopie, und der rote Faden ist einfach: Was hereinkommt, gehört danach Ihnen — nicht mehr dem Aufrufer.

10:16 Sie gehen also die Komponenten durch und fragen bei jeder, ob ihr Typ veränderlich ist. Für Sammlungen gibt es dafür die copyOf-Methoden, und die haben einen angenehmen Nebeneffekt: Sie liefern gleich eine unveränderliche Liste zurück, sodass auch das Herausgeben sicher ist. Bei Arrays müssen Sie zu clone greifen, dort gibt es kein copyOf.

10:35 Und bei Datumsangaben oder Zahlen lohnt der kurze Blick, ob der Typ nicht ohnehin schon unveränderlich ist — dann sparen Sie sich die Kopie. In dieser Aufgabe schließen Sie genau die Lücke, die wir eben gesehen haben. Die Fähigkeit, die Sie dabei üben, ist weniger das Tippen von copyOf als das Erkennen: An welcher Stelle endet die Zusage meines Typs?

10:56 Der Test dazu ist angenehm konkret — Sie verändern nach dem Erzeugen die übergebene Liste und schauen, ob der Record das mitbekommt. Wenn er unverändert bleibt, sitzt die Kopie. Und dann noch ein zweiter Blick, den viele vergessen: Was gibt eigentlich Ihre Zugriffsmethode zurück? Auch dort darf niemand hineinschreiben können.

11:16 Diese vier Fehler haben eines gemeinsam: Sie sehen im Code völlig harmlos aus. Der erste ist die halbe Absicherung — beim Hineingeben kopieren, beim Herausgeben die Originalliste liefern. Der zweite ist eine begriffliche Verwechslung: unmodifiableList erzeugt keine Kopie, sondern nur eine Sicht auf dieselbe Liste; ändert der Aufrufer sein Original, ändert sich auch Ihre Sicht.

11:38 Der dritte ist banal und trotzdem häufig — Null-Prüfungen fehlen, weil beim Erzeugen niemand warnt. Und der vierte betrifft den Entwurf: Wenn Prüfungen in einer statischen Fabrikmethode stehen, führt am Konstruktor vorbei immer noch ein Weg an ihnen vorbei.

Kompakte Konstruktoren

11:53 Kommen wir zurück zu dem Ärgernis vom Ende des letzten Kapitels: Der selbst geschriebene Konstruktor holt genau den Rumpfcode zurück, den wir eigentlich loswerden wollten — die wiederholte Parameterliste und die Zuweisungen. Java hat dafür eine eigene Schreibweise vorgesehen. Sie ist kurz, sie ist elegant, und sie zeigt beim Lesen sofort, was an diesem Konstruktor besonders ist.

12:15 Sie enthält allerdings auch einen Kniff, an dem praktisch jeder beim ersten Mal hängen bleibt. Den sehen wir uns genau an. Die kompakte Konstruktorsyntax lässt einfach weg, was ohnehin feststeht. Sie schreiben den Namen des Records und direkt dahinter den Rumpf — keine Parameterliste. Der Compiler ergänzt die Parameter aus den Komponenten und hängt die Zuweisungen ans Ende des Rumpfs. Was übrig bleibt, ist genau Ihre eigene Logik.

12:40 Das ist mehr als Schreibersparnis: Wer diesen Konstruktor liest, sieht sofort, was daran besonders ist, weil das Gewöhnliche gar nicht mehr dasteht. Genau das war die Absicht hinter Records — das Interessante sichtbar machen, indem man das Erwartbare verschwinden lässt. Und hier ist der Konstruktor von vorhin in seiner kompakten Form. Achten Sie auf die letzte Zeile im Rumpf, denn dort steckt der Kniff.

13:05 Zugewiesen wird nicht dem Feld, sondern dem Parameter. Das wirkt zunächst falsch — und ist genau richtig. Die vom Compiler ergänzte Zuweisung greift nämlich auf die Parametervariable zu, und die haben Sie in dieser Zeile bereits durch die Kopie ersetzt. Wenn Sie sich merken wollen, was hier passiert: Der kompakte Rumpf ist die letzte Gelegenheit, an den Werten etwas zu ändern, bevor sie in den Feldern landen.

13:29 Warum geht die naheliegende Variante nicht? Weil die Komponentenfelder final sind und nur ein einziges Mal beschrieben werden dürfen. Diese eine Zuweisung erzeugt der Compiler am Ende des kompakten Rumpfs — der Platz ist also schon vergeben. Ein Schreibversuch auf this-Punkt-nummer bricht deshalb bereits beim Übersetzen ab, und das ist gut so: Der Fehler taucht sofort auf, nicht irgendwann im Betrieb.

13:51 Wenn Sie die Regel einmal so verstanden haben, ist die Schreibweise plötzlich logisch statt merkwürdig. Sie ändern den Wert, den der Compiler gleich einsetzen wird. Ein Record darf übrigens mehr als einen Konstruktor haben — das wird gern vergessen. Es gibt aber eine strenge Regel: Jeder zusätzliche Konstruktor muss als allererste Anweisung einen anderen Konstruktor aufrufen.

14:13 Am Ende dieser Kette steht immer der kanonische, denn nur er beschreibt die Felder. Diese Regel klingt nach Bürokratie, hat aber einen sehr praktischen Effekt: Egal auf welchem Weg ein Record entsteht, Ihre Prüfungen im kanonischen Konstruktor laufen garantiert. Es gibt keine Hintertür, an der die Validierung vorbeiführt.

14:32 Ein typischer Anwendungsfall dafür sieht so aus. Nicht jeder Artikel hat beim Anlegen schon Etiketten, also bieten wir einen bequemeren Einstieg an — und setzen dabei eine leere Liste ein statt null. Das ist eine kleine Entscheidung mit großer Wirkung: Wer später über die Etiketten läuft, muss nie prüfen, ob überhaupt welche da sind.

14:52 Beachten Sie die erste Zeile im Rumpf, den this-Aufruf. Er ist hier nicht Stil, sondern Vorschrift — und sorgt dafür, dass auch dieser bequeme Weg durch die Nummernprüfung läuft. Diese Regeln wirken auf den ersten Blick wie eine willkürliche Liste. Dahinter steht aber ein einziger Gedanke: Ein Record soll klein bleiben.

15:10 Deshalb gibt es genau eine Stelle, an der Felder beschrieben werden, und deshalb münden alle Wege dorthin. Deshalb darf der kanonische Konstruktor auch nicht enger sichtbar sein als der Record selbst — sonst hätten Sie einen öffentlichen Typ, den niemand erzeugen kann. Und deshalb gibt es die Kompaktform. Wenn Sie sich die Regeln nicht merken wollen, merken Sie sich die Absicht: Ein Record ist ein Datencontainer, kein Ort für Fabriklogik.

15:36 Diese Aufgabe ist eine reine Umbauübung — und trotzdem lehrreich, weil sie Sie zwingt, zwei Dinge zu trennen, die vorher vermischt waren: Ihre eigene Logik und die mechanische Zuweisung an die Felder. Wenn der Umbau sitzt, steht im Rumpf nur noch, was Sie tatsächlich entschieden haben. Ein guter Prüfstein ist, dass Ihre bestehenden Tests unverändert durchlaufen — die Fassade des Typs hat sich ja nicht geändert.

15:59 Ergänzen Sie danach den Zusatzkonstruktor ohne Etiketten und überzeugen Sie sich, dass auch er die Prüfung durchläuft. Der erste Punkt ist der Klassiker, den wir eben besprochen haben — die Zuweisung an this. Wer den Grund kennt, macht ihn nur einmal. Der zweite ist ein Versehen mit Folgen: Bleibt die Parameterliste stehen, haben Sie unbemerkt wieder die Langform, und die Zuweisungen fehlen plötzlich.

16:22 Der dritte betrifft die this-Regel bei Zusatzkonstruktoren; Java ist da kompromisslos. Und der vierte ist ein Entwurfsfehler, der erst spät auffällt: Ein privater kanonischer Konstruktor in einem öffentlichen Record macht den Typ für Aufrufer unbrauchbar — erlaubt ist er ohnehin nicht.

Methoden in Records

16:39 Bleibt die letzte Frage dieses Moduls, und es ist eine Entwurfsfrage: Was darf eigentlich noch in einen Record hinein? Die Antwort ist großzügiger, als viele erwarten — ein Record ist schließlich eine Klasse, und fast alles, was Sie in einer Klasse dürfen, dürfen Sie auch hier. Es gibt genau eine Einschränkung. Die wirkt zunächst willkürlich, verrät aber alles über den Charakter dieses Sprachmittels.

17:02 Und sie hilft Ihnen dabei zu entscheiden, wann ein Record das richtige Werkzeug ist und wann nicht. Ein Record ist eine Klasse, und deshalb dürfen Sie hier fast alles, was Sie in einer Klasse dürfen: eigene Methoden, statische Felder, statische Methoden. Die eine Ausnahme betrifft Instanzfelder — die einzigen erlaubten sind die Komponentenfelder.

17:22 Diese Grenze ist kein Schikane, sondern das eigentliche Versprechen des Typs: Was Sie in der Komponentenliste sehen, ist der vollständige Zustand des Objekts. Es gibt nichts Verstecktes. Genau darauf verlassen sich equals, hashCode und toString — und darauf verlässt sich auch jeder, der Ihren Code liest. Hier sehen Sie, wie das in der Praxis aussieht. Die Methode beantwortet eine fachliche Frage — ist dieser Artikel sperrig?

17:48 — und sie tut das ausschließlich aus den vorhandenen Komponenten. Das ist das Muster, auf das es ankommt: Abgeleitete Werte werden berechnet, nicht gespeichert. Wer versucht ist, das Ergebnis in einem Feld zwischenzuspeichern, stößt sofort an die Grenze von vorhin — und das ist auch gut so, denn ein zwischengespeicherter Wert wäre wieder ein Zustand, der von den Komponenten abweichen kann.

18:10 Statische Felder wie die Konstante hier oben sind dagegen unproblematisch. Damit sind wir bei der Entwurfsfrage, die dieses Modul abschließt: Wann ist ein Record das richtige Mittel und wann nicht? Die Faustregel lautet: Ein Record ist die Wahrheit über seine Daten, nicht über deren Verarbeitung. Alles, was sich aus den Komponenten berechnen lässt, darf als Methode dazu — das macht den Typ sogar besser, weil die Frage dort steht, wo die Daten liegen.

18:36 Sobald aber Zustand ins Spiel kommt, der sich unabhängig ändert, sind Sie bei einer gewöhnlichen Klasse. Diese Unterscheidung ist wichtiger als jede Syntaxregel, die wir heute besprochen haben. In dieser Aufgabe wenden Sie das Gelernte auf einen neuen Typ an — und die eigentliche Übung ist eine Verlagerung. Statt beim Aufrufer aus zwei Werten eine Bezeichnung zusammenzusetzen, formulieren Sie diese Frage als Methode auf dem Record.

19:02 Der Gewinn zeigt sich, sobald zwei verschiedene Stellen dieselbe Frage stellen. Achten Sie darauf, dass Ihre Methode ohne zusätzliches Feld auskommt — das ist der Prüfstein dafür, ob der Wert wirklich abgeleitet ist. Ein guter Kandidat: eine lesbare Bezeichnung aus Zone und Regalnummer. Zum Abschluss noch vier Fallen. Die erste kennen Sie nun — das zwischengespeicherte Ergebnis als Feld.

19:26 Die zweite ist ein alter Bekannter aus der Java-Welt: equals überschreiben und hashCode vergessen. Im Record passiert das selten, aber wenn, dann fällt es erst im HashSet auf, also spät. Die dritte ist ein Sicherheitsthema, das gern übersehen wird: toString bezieht alle Komponenten ein — wenn dort ein Zugangsschlüssel liegt, steht er im Logfile.

19:46 Und die vierte ist ein schleichender Prozess: Ein Record, dem man Stück für Stück Geschäftslogik anhängt, ist irgendwann keiner mehr. Fassen wir zusammen. Ein Record erklärt seine Daten, den Rest übernimmt der Compiler — das spart nicht nur Tipparbeit, sondern eine ganze Klasse von Vergessensfehlern. Prüfung und defensive Kopie gehören in den kanonischen Konstruktor, weil alle Wege dort hindurchführen.

20:11 Die Kompaktform hält den Konstruktor lesbar, indem sie nur Ihre eigene Logik zeigt. Und die Grenze des Typs ist die Komponentenliste: eigene Methoden ja, weitere Instanzfelder nein. Im nächsten Modul kommt das Gegenstück dazu — Records sagen, woraus etwas besteht; versiegelte Typen sagen, was es alles sein kann.