Instanceof außerhalb der equals-Methode: Unterschied zwischen den Versionen
K (Ls0758 verschob die Seite Verwendung von instancefOf nach Verwendung von instanceOf: Typo) |
Keine Bearbeitungszusammenfassung |
||
Zeile 2: | Zeile 2: | ||
|baustelle=Ja | |baustelle=Ja | ||
|blatt=1 | |blatt=1 | ||
|beschreibung=Die | |beschreibung=Die Java API bietet uns das Schlüsselwort <syntaxhighlight inline lang="Java">instanceOf</syntaxhighlight>, um zu prüfen, ob eine Objekt eine Instanz einer bestimmten Schnittstelle (Interface) oder Klasse ist. | ||
In | In aller Regel kann die Verwendung von <syntaxhighlight lang="Java" inline>instanceOf</syntaxhighlight> durch den Einsatz von Polymorphie umgangen werden, das heißt, man definiert eine Methode in der Oberklasse/im Interface, von dem alle betroffenen Klassen erben, die das gewünschte Verhalten umsetzt. Die Verwendung von <syntaxhighlight lang="Java" inline>instanceOf</syntaxhighlight> gilt daher als äußerst schlechter Stil. | ||
Im Rahmen dieses Übungsbetriebs ist die Verwendung von <syntaxhighlight lang="Java" inline>instanceOf</syntaxhighlight> somit unzulässig. | |||
Eine einzige Ausnahme besteht in der Implementierung der [https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#equals-java.lang.Object- equals(Object o)]-Methode einer Klasse. Üblicherweise prüft man in eigenen Implementierungen von <syntaxhighlight lang="Java" inline>equals</syntaxhighlight> zuallererst, ob das "andere" Objekt <syntaxhighlight lang="Java" inline>null</syntaxhighlight> ist, und wenn nicht, ob eine Instanz der entsprechenden Klasse ist. Diese beiden Prüfungen sind in einer <syntaxhighlight lang="Java" inline>instanceOf</syntaxhighlight>-Abfrage möglich, wie im Positivbeispiel beschrieben. Zu diesem Zweck ist der Einsatz von <syntaxhighlight lang="Java" inline>instanceOf</syntaxhighlight> erlaubt. | |||
|schweregrad=leicht | |schweregrad=leicht | ||
|negativ=Mit instanceOf können wir natürlich auch außerhalb der besagten equals Methode Vergleiche aufstellen. Jedoch ist das in vielen Fällen eine sehr unsaubere Lösung für ein Problem: | |negativ=Mit instanceOf können wir natürlich auch außerhalb der besagten equals Methode Vergleiche aufstellen. Jedoch ist das in vielen Fällen eine sehr unsaubere Lösung für ein Problem: |
Version vom 17. Oktober 2024, 11:49 Uhr
🚧 | Diese Seite befindet sich in Bearbeitung | 🚧 |
🤓 | Diese Seite ist eine Bewertungsrichtlinie, die ab Blatt 1 annotiert und ab Blatt 2 abgezogen wird. | 🤓 |
Beschreibung
Die Java API bietet uns das Schlüsselwort instanceOf
, um zu prüfen, ob eine Objekt eine Instanz einer bestimmten Schnittstelle (Interface) oder Klasse ist.
In aller Regel kann die Verwendung von instanceOf
durch den Einsatz von Polymorphie umgangen werden, das heißt, man definiert eine Methode in der Oberklasse/im Interface, von dem alle betroffenen Klassen erben, die das gewünschte Verhalten umsetzt. Die Verwendung von instanceOf
gilt daher als äußerst schlechter Stil.
Im Rahmen dieses Übungsbetriebs ist die Verwendung von instanceOf
somit unzulässig.
Eine einzige Ausnahme besteht in der Implementierung der equals(Object o)-Methode einer Klasse. Üblicherweise prüft man in eigenen Implementierungen von equals
zuallererst, ob das "andere" Objekt null
ist, und wenn nicht, ob eine Instanz der entsprechenden Klasse ist. Diese beiden Prüfungen sind in einer instanceOf
-Abfrage möglich, wie im Positivbeispiel beschrieben. Zu diesem Zweck ist der Einsatz von instanceOf
erlaubt.
Negativbeispiel
Mit instanceOf können wir natürlich auch außerhalb der besagten equals Methode Vergleiche aufstellen. Jedoch ist das in vielen Fällen eine sehr unsaubere Lösung für ein Problem:
public void talk(Person[] persons) {
for (Person person : persons) {
if (person instanceOf InfoStudent) {
System.out.println("Ich studiere Informatik...");
} else if (person instanceOf Employee) {
System.out.println("Ich arbeite in der Indusrie...");
}
}
}
Es ist hier eine viel bessere Lösung, in der Klasse Person eine abstrakte Methode zu definieren, die einen String zurück- oder ausgibt. Diese Methode sollte dann von der Employee und InfoStudent Klasse geerbt und implementiert werden.
Positivbeispiel
class Book {
[...]
@Override
public boolean equals(Object obj) {
// This will also do an implicit null-check so we don't have to worry about that here
return (obj instanceOf this);
}
}