Antwort.

Historie der Frage

Der instanceof-Operator wurde in Java eingeführt, um die Möglichkeit zu bieten, zu überprüfen, ob ein Objekt einem bestimmten Typ (Klasse oder Schnittstelle) angehört, bevor Typumwandlungen durchgeführt werden. Dies wurde relevant für die Arbeit mit Vererbung, Polymorphismus und die Handhabung von heterogenen Objektkollektionen.

Problem

Ohne Überprüfung der Typzugehörigkeit kann eine ClassCastException auftreten, wenn Typumwandlungen durchgeführt werden. Eine falsche Verwendung von instanceof kann die Architektur des Codes verschlechtern und zu Antipatterns führen (z. B. häufige Verwendung statt Polymorphismus).

Lösung

Der instanceof-Operator gibt true zurück, wenn das Objekt nicht null ist und dem überprüften Typ angehört oder die angegebene Schnittstelle implementiert.

Beispielcode:

Object obj = "Hello";
if (obj instanceof String) {
    String str = (String) obj;
    System.out.println(str.toUpperCase());
}

Wichtige Merkmale:

• Typprüfung zur Laufzeit (run-time)
• Sichere Typumwandlungen nach der Prüfung
• Bei null-Werten wird immer false zurückgegeben

Trickfragen.

Was gibt obj instanceof SomeClass zurück, wenn obj == null?

instanceof gibt immer false zurück, wenn das Objekt null ist, unabhängig vom überprüften Typ. Dies ist wichtig, um eine NullPointerException zu verhindern.

Kann man instanceof zur Überprüfung der Implementierung einer Schnittstelle verwenden?

Ja. instanceof wird verwendet, um zu überprüfen, ob ein Objekt die benötigte Schnittstelle implementiert und nicht nur zur Zugehörigkeit zu einer bestimmten Klasse.

Beispielcode:

Runnable r = () -> {};
System.out.println(r instanceof Runnable); // true

Was passiert, wenn die Klasse mit --release 16+ kompiliert wird und das Pattern Matching für instanceof bereits implementiert ist?

Seit Java 16+ unterstützt der instanceof-Operator Pattern Matching, d. h. man kann die Variable direkt in der Prüfung angeben und das explizite Casting vermeiden.

Beispielcode:

Object obj = "Test string";
if (obj instanceof String str) {
    System.out.println(str.length());
}

Typische Fehler und Antipatterns

• Flächendeckende Verwendung von instanceof statt Polymorphismus (Verstoß gegen OOP)
• Aufruf von instanceof für Objekte, die logisch nicht zu der angegebenen Klasse gehören können (strukturfehler)
• Fehlende Behandlung des Null-Falls

Beispiel aus der Praxis

Negativer Fall

In einem großen Projekt wurde die Logik der Geschäftsverarbeitung auf eine Reihe von if (obj instanceof X)... aufgebaut, anstatt Methoden zu überschreiben. Das erschwerte die Wartung: Das Hinzufügen eines neuen Typs erforderte, alle Überprüfungen zu ändern.

Vorteile:

• Schnelle Implementierung zusätzlicher Logik

Nachteile:

• Erschwerte Unterstützung
• Skalierbarkeitsprobleme

Positiver Fall

In einem ähnlichen Projekt wurde für eine erweiterbare Hierarchie abstrakte Methoden verwendet, und instanceof nur zur Überprüfung spezieller Edge-Cases.

Vorteile:

• Saubere Architektur
• Minimierung von Fehlern bei der Hinzufügung neuer Klassen

Nachteile:

• Durchdachte Klassenauswahl erforderlich
• Möglicherweise leichte Überflüssigkeit bei der Verarbeitung seltener Fälle