Was ist der Unterschied zwischen instanceof und Class.isAssignableFrom(...)?

Question

Welche der folgenden Möglichkeiten ist besser?

a instanceof B

oder

B.class.isAssignableFrom(a.getClass())

Der einzige Unterschied, der mir bekannt ist, besteht darin, dass die erste Methode false zurückgibt, wenn 'a' null ist, während die zweite eine Ausnahme auslöst. Liefern sie sonst immer das gleiche Ergebnis?

Answer 1

Es gibt noch einen weiteren Unterschied. Wenn der Typ (Klasse), gegen den getestet werden soll, dynamisch ist, z. B. als Methodenparameter übergeben wird, dann ist instanceof für Sie nicht geeignet.

boolean test(Class clazz) {
   return (this instanceof clazz); // clazz cannot be resolved to a type.
}

aber Sie können es:

boolean test(Class clazz) {
   return (clazz.isAssignableFrom(this.getClass())); // okidoki
}

Ups, wie ich sehe, ist diese Antwort bereits abgedeckt. Vielleicht ist dieses Beispiel für jemanden hilfreich.

Answer 2

Dieser Thread hat mir einen Einblick gegeben, wie instanceof unterschieden von isAssignableFrom also dachte ich, ich teile etwas von mir selbst mit.

Ich habe festgestellt, dass die Verwendung von isAssignableFrom die einzige (wahrscheinlich nicht die einzige, aber möglicherweise die einfachste) Möglichkeit, sich selbst zu fragen, ob eine Referenz einer Klasse Instanzen einer anderen annehmen kann, wenn man keine Instanzen einer der beiden Klassen hat, um den Vergleich durchzuführen.

Daher fand ich die Verwendung des instanceof Operator, um die Zuordenbarkeit zu vergleichen, eine gute Idee sein, wenn alles, was ich hatte, waren Klassen, es sei denn, ich erwog, eine Instanz aus einer der Klassen zu erstellen; Ich dachte, das wäre schlampig.

Answer 3

Instanceof kann auch nicht mit primitiven Typen oder generischen Typen verwendet werden. Wie im folgenden Code:

//Define Class< T > type ... 

Object e = new Object();

if(e instanceof T) {
  // Do something.
}

Der Fehler ist: Cannot perform instanceof check against type parameter T. Use it's erasure Object instead since further generic type information will be erased at runtime.

Lässt sich nicht kompilieren, da die Laufzeitreferenz durch Typlöschung entfernt wurde. Der folgende Code lässt sich jedoch kompilieren:

if( type.isAssignableFrom(e.getClass())){
  // Do something.
}

Answer 4

Stellen Sie sich folgende Situation vor. Angenommen, Sie wollen prüfen, ob Typ A eine Superklasse des Typs von obj ist, dann können Sie entweder

... A.class.isAssignableFrom(obj.getClass()) ...

OR

... obj instanceof A ...

Aber die isAssignableFrom-Lösung erfordert, dass der Typ des Objekts hier sichtbar ist. Ist dies nicht der Fall (z.B. könnte der Typ von obj zu einer privaten inneren Klasse gehören), scheidet diese Option aus. Die instanceof-Lösung würde jedoch immer funktionieren.

Answer 5

Es hängt alles davon ab, was Sie an dieser Stelle des Codes zur Verfügung haben. Ich würde nicht empfehlen, die isAssignableFrom Wenn Sie mit einem tatsächlichen Objekt arbeiten, gibt es eine bessere Option. Hier ist eine Rangliste von Empfehlungen, je nachdem, was Sie zur Verfügung haben:

• Wenn Sie ein Objekt haben a und Sie kennen den Typ B zur Kompilierzeit:

  a instanceof B

• Wenn Sie ein Objekt haben a und Sie kennen den Typ nicht B aber Sie haben ein Objekt b :

  b.getClass().isInstance(a)

• Wenn Sie ein Objekt haben a und Sie haben keinen Typ zur Kompilierzeit ODER ein instanziiertes Objekt, aber Sie haben ein Klassenobjekt Class<?> someBClass :

  someBClass.isInstance(a)

• Wenn Sie keine instanziierten Objekte haben, aber Sie haben zwei Class<?> Objekte:

  someBClass.isAssignableFrom(someAClass) .

Angenommen, Sie fangen ganz oben auf der Liste an und arbeiten sich nach unten vor, dann ist jeder dieser Punkte der einfachste Weg, um Ihr Ziel zu erreichen, und basiert auf meiner eigenen Forschung Ich glaube dass Sie auch die bestmögliche Leistung erhalten.