Antwort.

Geschichte der Frage

Pattern Matching ist ein Konzept, das aus funktionalen und Skriptsprache übernommen wurde und es ermöglicht, den Typ zu überprüfen und Daten in einem Schritt zu extrahieren. Die Entwicklung des Pattern Matching in Java begann mit Java 14 (Vorschau-Feature), wurde in Java 16–17 verbessert und wird in den letzten Releases auf switch ausgeweitet.

Problem

Die klassische Art der Typüberprüfung und -umwandlung sah umständlich aus:

if (obj instanceof String) {
    String s = (String) obj;
    ...
}

Es gab überflüssige Variablen, viel Boilerplate-Code und ein Risiko von Typkonvertierungsfehlern.

Lösung

Pattern Matching ermöglicht es, die Typüberprüfung, die Deklaration einer neuen Variablen und deren Verwendung in einem Ausdruck zu kombinieren:

if (obj instanceof String s) {
    System.out.println(s.length());
}

Ähnliche Muster erscheinen jetzt auch in switch-Konstruktionen, was den Code prägnanter und weniger fehleranfällig macht.

Wesentliche Merkmale:

Prägnante und sichere Arbeit mit Typen.
Reduzierung der Fehlerwahrscheinlichkeit bei Casts.
Einfache Wartung des Codes und Erweiterung auf neue Typen.

Fragen mit Vorwurf.

Kann man Pattern Matching für benutzerdefinierte Klassen verwenden oder nur für Standardtypen?

Es kann für alle Klassen verwendet werden. Pattern Matching funktioniert für alle Klassen, auf die instanceof angewendet werden kann.

Wird die Pattern-Variable außerhalb des if/switch-Blocks verfügbar sein?

Nein, die innerhalb des Pattern Matching deklarierte Variable ist nur innerhalb des Blocks sichtbar, in dem sie erstellt wurde (zum Beispiel innerhalb von if oder case switch).

Beispielcode:

if (obj instanceof Integer i) {
    // i ist nur in diesem Block sichtbar
    System.out.println(i + 10);
}
// Hier ist i nicht verfügbar

Kann man Pattern Matching mit Generika verwenden?

Ja, so:

Object list = List.of("a", "b");
if (list instanceof List<?> l) {
    System.out.println(l.size());
}

Aber die Arbeit mit Raw-Typen und die Umwandlung in parametrisiert Typen ist aufgrund von Type Erasure immer noch eingeschränkt.

Typische Fehler und Anti-Patterns

Die Annahme, dass Pattern Matching null automatisch behandelt: Wenn das Objekt null ist, wird die Bedingung nicht erfüllt (instanceof mit null ist immer false).
Verwendung von Pattern Matching, wo die Methode getClass() ausreicht.
Zu häufige Anwendung von Pattern Matching kann die Architektur verschlechtern, wenn die Absichten unklar sind.

Beispiel aus dem Leben

Negativer Fall

Das Team führte Pattern Matching in allen Fällen ein, einschließlich interner DTOs, Servicelayer und Fälle, in denen Polymorphismus ausgereicht hätte. Der Code wurde zu stark an instanceof gebunden, die Rolle der Klassenhierarchien wurde verwischt.

Vorteile:

Schnelle Implementierung.
Prägnanter Stil.

Nachteile:

Architektonische Fehlkalkulationen.
Geringere Lesbarkeit.

Positiver Fall

Im Projekt wurde Pattern Matching nur für allgemeine Schnittstellen, Hilfsklassen und die Verarbeitung von Sammlungen unbekannten Typs verwendet. Die OOP-Architektur blieb erhalten, die Verwendung des Musters wurde auf die Stellen beschränkt, wo es wirklich notwendig war.