class.isInstance vs. instanceof

[Bio]

Sup!

Leider bin ich zu doof, den Unterschied zwischen class.isInstance() und instanceof zu verstehen.

Suchergebnisse legen nahe, dass class.isInstance irgendwie flexibler und dynamischer ist und man damit Dinge vergleichen kann, von denen man selbst nicht weiss, welche man überhaupt vergleicht...

Aber ich finde kein Beispiel, wo instanceof nicht reicht und class.isInstance() die Rettung ist.

Vielleicht haben wir Java-Gurus da?

Gruesse,

Bio

[Rouven]

Hello,

Leider bin ich zu doof, den Unterschied zwischen class.isInstance() und instanceof zu verstehen.

Das JavaDoc zu Class.isInstance sagt es eigentlich ganz schön - es ist die objektorientierte Variante von instanceof. Bedenke: instanceof muss der Entwickler in den Code schreiben. Wie stellst du aber zur Laufzeit fest, ob ein Objekt Instanz einer Klasse ist, wenn du vorher nicht weißt, auf welche Klasse du prüfen willst.
obj instanceof aFixedClass ist fest verdrahtet und setzt voraus, dass du zur Compilezeit aFixedClass kennst.
anUnknownClass.isInstance(obj) ist dynamisch und setzt nur voraus, dass du die Laufzeitklasse von anUnknownClass kennst.

MfG
Rouven

[Bio]

Sup!

Das JavaDoc zu Class.isInstance sagt es eigentlich ganz schön - es ist die objektorientierte Variante von instanceof. Bedenke: instanceof muss der Entwickler in den Code schreiben. Wie stellst du aber zur Laufzeit fest, ob ein Objekt Instanz einer Klasse ist, wenn du vorher nicht weißt, auf welche Klasse du prüfen willst.
obj instanceof aFixedClass ist fest verdrahtet und setzt voraus, dass du zur Compilezeit aFixedClass kennst.
anUnknownClass.isInstance(obj) ist dynamisch und setzt nur voraus, dass du die Laufzeitklasse von anUnknownClass kennst.

Okay...

Aber ... öh ... was muss man für abgefahrene Dinge tun, damit man irgendwelche Objekte hat, von denen man nicht weiss, welchen Typ sie haben, und irgendwelche Klassen, von denen man auch nichts weiss, so dass man testen muss, ob irgendwelche Objekte Instanz irgendwelcher Klassen sind?

Und irgendwie habe ich das Gefühl, in meinem Use-Case würde instanceof reichen:

1. Ich habe Objekte, die alle Instanzen von Klassen sind, die das Interface "IEntity" implementieren (das sind ggf. ganz verschiedene Klassen).
2. Es gibt ein Interface "IValueSpecification", das "IEntity" (allerdings um drei Ecken) erweitert (IValueSpecification extends (...) extends IEntity)
3. Ich habe ein Objekt "o", von dem ich nur weiss, dass es das Interface "IEntity" implementiert (weil ich es von einer Methode bekomme, deren Rückgabewert IEntity ist) von dem ich testen will, ob es auch das Interface "IValueSpecification" implementiert.

Nun sagen die lokalen Java-Gurus, ich muss das mit

"IValueSpecification.class.instanceOf(o)" testen, weil es anders nicht gehen würde.

Und ich verstehe jetzt nicht, warum

"o instanceof IValueSpecification"

nicht gehen soll. Eclipse meckert beides nicht an...

Die Interfaces sind irgendwie nur Proxies mit public access für die wirklichen Objekte, die aus irgendeiner Datenbank kommen und verborgen sind und wo ein geheimnisvoller Persistenz-Layer drüberliegt, der mit Reflection funktioniert etc..

Vielleicht kannst Du Dir vorstellen, was die da machen. Ich nicht ;-)

Gruesse,

Bio

[Rouven]

Hello,

Eclipse meckert beides nicht an...

jo, ich würde in deinem Fall auch für instanceof plädieren. Ich kann mir im Moment nicht vorstellen, warum das ein Problem sein soll.

Vielleicht kannst Du Dir vorstellen, was die da machen. Ich nicht ;-)

joa, ungefähr, the magic of JEE und Persistenzlayer - ist mir immer wieder unheimlich, aber funktioniert erfahrungsgemäß. Allerdings wissen glaube ich nur 42 Leute weltweit warum...

Die anderen kranken Konstellationen, na ja, du musst immer überlegen, dass zur Laufzeit noch vieles auf Java aufsetzen kann, Annotations zur Laufzeit lesen, Übersetzungen machen, Injections machen. Objekte zur Laufzeit dynamisch initialisieren, z.B. auf Basis von Strings. Nehmen wir nur an du hättest ein Propertyfile in dem steht du mögest Object x auf instanceof Klasse y prüfen (dynamische Konfiguration von Testfällen). Da kannst du schlecht instanceof im Code streuen...

MfG
Rouven

[Bio]

Sup!

»» Vielleicht kannst Du Dir vorstellen, was die da machen. Ich nicht ;-)
joa, ungefähr, the magic of JEE und Persistenzlayer - ist mir immer wieder unheimlich, aber funktioniert erfahrungsgemäß. Allerdings wissen glaube ich nur 42 Leute weltweit warum...

Naja, ich werd' einfach mal tun, was die gesagt haben, und zu gegebener Zeit nochmal mit einem Kollegen sprechen, der gerade im Urlaub ist, aber mehr Ahnung von Java hat als ich, warum die meinen, ich soll instanceOf nehmen...

Aber ich vermute mal, diese Java-Guru-Typen haben einfach die Basics aus den Augen verloren wegen der kranken Sachen, die sie die ganze Zeit machen müssen.

Gruesse,

Bio

[Sympathisant]

Hai,

»» Vielleicht kannst Du Dir vorstellen, was die da machen. Ich nicht ;-)
joa, ungefähr, the magic of JEE und Persistenzlayer - ist mir immer wieder unheimlich, aber funktioniert erfahrungsgemäß. Allerdings wissen glaube ich nur 42 Leute weltweit warum...

Hahah.. so ist das wohl ;-)

Bezgl. IsIstance.. findet so etwas nicht zb bei der Plugin-Programmierung Verwendung? Also genau dann, wenn ein Programm dynamisch Plugins einbettet und die Objektueberpruefung anhand zur Laufzeit definierter Kriterien stattfinden muss?

Ich kann aber auch durchaus daneben liegen ;-)

MfG,
Sympatisant

[dedlfix]

echo $begrüßung;

Aber ... öh ... was muss man für abgefahrene Dinge tun, damit man irgendwelche Objekte hat, von denen man nicht weiss, welchen Typ sie haben, und irgendwelche Klassen, von denen man auch nichts weiss, so dass man testen muss, ob irgendwelche Objekte Instanz irgendwelcher Klassen sind?

Es gibt diverse Dinge beim Programmieren, die muss man einfach nur mal gehört haben. Man wird sie vielleicht nicht einsetzen. Aber manchmal kommt man bei einem bestimmten Problem an einen Punkt, an dem man das einsetzen kann und dann weiß man, wozu es gut ist. Das ist quasi wie beim Märchen von einem der auszog, das fürchten zu lernen. Irgendwann hatte er die Situation, die er sich vorher gar nicht vorstellen konnte.

Es ist ja nicht so, dass man gar nichts weiß, aber manchmal schreibt man generischen Code, der etwas bestimmtest macht, aber es dem Anwender offen lässt, welchen Typ er konkret einsetzen will. Ein Beispiel wäre eine Liste. Die zur Verwaltung notwendigen Methoden braucht man immer wieder, aber bei stark typisierten Sprachen will man nicht für jeden Typ diese Verwaltung erneut implementieren. Also nimmt man eine generische Listenklasse. Der konkrete Typ wird zur Laufzeit beim Erzeugen eines Objekts dieser generischen Listenklasse mitgegeben. Und schon hat man Code, bei dem man nicht weiß, was für einen konkreten Typ man zur Laufzeit zu verwalten hat. Man muss aber vielleicht testen, ob ein zur Liste neu hinzuzufügendes Objekt den gleichen Typ hat wie bei der Initialisierung der Listen-Instanz angegeben wurde.

echo "$verabschiedung $name";

[Bio]

Sup!

Es ist ja nicht so, dass man gar nichts weiß, aber manchmal schreibt man generischen Code, der etwas bestimmtest macht, aber es dem Anwender offen lässt, welchen Typ er konkret einsetzen will. Ein Beispiel wäre eine Liste. Die zur Verwaltung notwendigen Methoden braucht man immer wieder, aber bei stark typisierten Sprachen will man nicht für jeden Typ diese Verwaltung erneut implementieren. Also nimmt man eine generische Listenklasse. Der konkrete Typ wird zur Laufzeit beim Erzeugen eines Objekts dieser generischen Listenklasse mitgegeben. Und schon hat man Code, bei dem man nicht weiß, was für einen konkreten Typ man zur Laufzeit zu verwalten hat. Man muss aber vielleicht testen, ob ein zur Liste neu hinzuzufügendes Objekt den gleichen Typ hat wie bei der Initialisierung der Listen-Instanz angegeben wurde.

Na okay... dann mag das so im Sinne von quasi Template-basiertem Programmieren Sinn ergeben. Aber in meinem Use-Case weiss ich ja, was ich erwarte; von daher weiss ich wirklich nicht, was die mit ihrem class.instanceOf wollen.

Danke auf jeden Fall!

Gruesse,

Bio