Wie nutzt du Records, sealed Types und Pattern Matching in modernem Java?

Records sind transparente unveränderliche Träger: du deklarierst die Komponenten und bekommst kanonischen Konstruktor, Accessoren, equals, hashCode und toString. Sealed Interfaces schränken ein, welche Typen sie implementieren dürfen, ein Switch über diese Typen kann also zur Compile-Zeit auf Vollständigkeit geprüft werden, ganz ohne default-Zweig. Record Patterns lassen dich dann im Switch destrukturieren, was eine Kette von instanceof-Casts in ein lesbares Statement verwandelt.

Ich nutze sie zusammen. Ein sealed Interface deklariert die geschlossene Menge an Fällen, jeder Fall ist ein Record mit eigenen Komponenten, und dann behandelt ein Switch mit Record Patterns sie. Ein Zahlungsergebnis wird also zu einem sealed Interface mit den Records Approved, Declined und Pending, und der Switch destrukturiert jeden davon direkt in seine Felder. Der Compiler erzwingt Vollständigkeit, und das ist der eigentliche Nutzen: fügt jemand einen vierten Fall hinzu, lässt sich jeder Switch über den Typ nicht mehr compilieren, statt still in einen default-Zweig zu fallen und das Falsche zu tun. Records haben mir außerdem korrektes equals und hashCode geschenkt, und ein kompakter Konstruktor ist der natürliche Ort zum Validieren, ein Betrag kann also in keiner existierenden Instanz negativ sein. Die Einschränkungen, die ich nenne: ein Record ist nur flach unveränderlich, ein Record mit einer Liste kann also über diese Liste trotzdem mutiert werden, solange ich sie im Konstruktor nicht kopiere, und sie passen schlecht zu JPA-Entities, die einen parameterlosen Konstruktor und veränderlichen Zustand wollen.