Une raison de préférer getClass () à instanceof lors de la génération de .equals ()?

J'utilise Eclipse pour générer .equals()et .hashCode(), et il existe une option intitulée "Utiliser 'instanceof' pour comparer les types". Par défaut, cette option est décochée et utilisée .getClass()pour comparer les types. Y at - il raison que je préférerais .getClass()plus instanceof?

Sans utiliser instanceof:

if (obj == null)
  return false;
if (getClass() != obj.getClass())
  return false;

Utilisation instanceof:

if (obj == null)
  return false;
if (!(obj instanceof MyClass))
  return false;

Je coche habituellement l' instanceofoption, puis j'entre et je supprime le " if (obj == null)" chèque. (Il est redondant car les objets nuls échoueront toujours instanceof.) Y a-t-il une raison pour laquelle c'est une mauvaise idée?

Si vous utilisez instanceof, ce qui rend votre equalsmise en œuvre finalpréservera le contrat de symétrie de la méthode: x.equals(y) == y.equals(x). Si cela finalsemble restrictif, examinez attentivement votre notion d'équivalence d'objet pour vous assurer que vos implémentations prédominantes maintiennent pleinement le contrat établi par la Objectclasse.

Josh Bloch privilégie votre approche:

La raison pour laquelle je préfère l' instanceofapproche est que lorsque vous utilisez l' getClassapproche, vous avez la restriction selon laquelle les objets ne sont égaux qu'à d'autres objets de la même classe, du même type d'exécution. Si vous étendez une classe et y ajoutez quelques méthodes inoffensives, vérifiez si un objet de la sous-classe est égal à un objet de la super classe, même si les objets sont égaux dans tous les aspects importants, vous obtiendrez le réponse surprenante qu'ils ne sont pas égaux. En fait, cela viole une interprétation stricte du principe de substitution de Liskov et peut conduire à un comportement très surprenant. En Java, c'est particulièrement important car la plupart des collections (HashTable, etc.) sont basées sur la méthode des égaux. Si vous placez un membre de la super classe dans une table de hachage en tant que clé et que vous le recherchez à l'aide d'une instance de sous-classe, vous ne le trouverez pas, car ils ne sont pas égaux.

Voir aussi cette réponse SO .

Le chapitre 3 de Effective Java couvre également cela.

Angelika Langers Secrets of equal entre dans cela avec une discussion longue et détaillée pour quelques exemples courants et bien connus, y compris par Josh Bloch et Barbara Liskov, découvrant quelques problèmes dans la plupart d'entre eux. Elle obtient également dans le instanceofcontre getClass. Quelques citations

Conclusions

Après avoir disséqué les quatre exemples choisis arbitrairement d'implémentations de equals (), que concluons-nous?

Tout d'abord: il existe deux manières substantiellement différentes d'effectuer la vérification de la correspondance de type dans une implémentation de equals (). Une classe peut permettre une comparaison de type mixte entre des objets super et sous-classe au moyen de l'opérateur instanceof, ou une classe peut traiter des objets de type différent comme non égaux au moyen du test getClass (). Les exemples ci-dessus illustrent bien que les implémentations de equals () utilisant getClass () sont généralement plus robustes que celles utilisant instanceof.

Le test instanceof n'est correct que pour les classes finales ou si au moins la méthode equals () est finale dans une superclasse. Ce dernier implique essentiellement qu'aucune sous-classe ne doit étendre l'état de la superclasse, mais ne peut ajouter que des fonctionnalités ou des champs qui ne sont pas pertinents pour l'état et le comportement de l'objet, tels que les champs transitoires ou statiques.

Les implémentations utilisant le test getClass () par contre respectent toujours le contrat equals (); ils sont corrects et robustes. Cependant, ils sont sémantiquement très différents des implémentations qui utilisent l'instance de test. Les implémentations utilisant getClass () ne permettent pas de comparer des objets de sous-classe avec des objets de superclasse, même si la sous-classe n'ajoute aucun champ et ne souhaite même pas remplacer equals (). Une telle extension de classe "triviale" serait par exemple l'ajout d'une méthode debug-print dans une sous-classe définie exactement pour cet objectif "trivial". Si la superclasse interdit la comparaison de type mixte via la vérification getClass (), alors l'extension triviale ne sera pas comparable à sa superclasse. Que ce soit un problème ou non dépend entièrement de la sémantique de la classe et du but de l'extension.

La raison de l'utilisation getClassest d'assurer la propriété symétrique du equalscontrat. De Equals 'JavaDocs:

Il est symétrique: pour toutes les valeurs de référence non nulles x et y, x.equals (y) doit retourner vrai si et seulement si y.equals (x) renvoie vrai.

En utilisant instanceof, il est possible de ne pas être symétrique. Prenons l'exemple: Dog étend Animal. Animal's equalseffectue une instanceofvérification d'Animal. Dog's equalsfait une instanceofvérification de Dog. Donnez Animal a et Chien d (avec les autres champs identiques):

a.equals(d) --> true
d.equals(a) --> false

Cela viole la propriété symétrique.

Pour suivre strictement le contrat d'égal, la symétrie doit être assurée, et donc la classe doit être la même.

C'est en quelque sorte un débat religieux. Les deux approches ont leurs problèmes.

• Utilisez instanceof et vous ne pourrez jamais ajouter de membres significatifs aux sous-classes.
• Utilisez getClass et vous enfreignez le principe de substitution de Liskov.

Bloch a un autre conseil pertinent dans Effective Java Second Edition :

• Point 17: Conception et document pour l'héritage ou l'interdire

Corrigez-moi si je me trompe, mais getClass () sera utile lorsque vous voulez vous assurer que votre instance n'est PAS une sous-classe de la classe avec laquelle vous comparez. Si vous utilisez instanceof dans cette situation, vous ne pouvez PAS le savoir car:

class A { }

class B extends A { }

Object oA = new A();
Object oB = new B();

oA instanceof A => true
oA instanceof B => false
oB instanceof A => true // <================ HERE
oB instanceof B => true

oA.getClass().equals(A.class) => true
oA.getClass().equals(B.class) => false
oB.getClass().equals(A.class) => false // <===============HERE
oB.getClass().equals(B.class) => true

Si vous voulez vous assurer que seule cette classe correspondra, utilisez getClass() ==. Si vous souhaitez faire correspondre des sous-classes, il instanceofest nécessaire.

En outre, instanceof ne correspondra pas à un null mais peut être comparé en toute sécurité à un null. Vous n'avez donc pas besoin de le vérifier.

if ( ! (obj instanceof MyClass) ) { return false; }

Cela dépend si vous considérez si une sous-classe d'une classe donnée est égale à son parent.

class LastName
{
(...)
}


class FamilyName
extends LastName
{
(..)
}

ici, j'utiliserais 'instanceof', car je veux qu'un LastName soit comparé à FamilyName

class Organism
{
}

class Gorilla extends Organism
{
}

ici, j'utiliserais «getClass», car la classe dit déjà que les deux instances ne sont pas équivalentes.

instanceof fonctionne pour les instances de la même classe ou ses sous-classes

Vous pouvez l'utiliser pour tester si un objet est une instance d'une classe, une instance d'une sous-classe ou une instance d'une classe qui implémente une interface particulière.

ArryaList et RoleList sont tous deux instances de List

Tandis que

getClass () == o.getClass () ne sera vrai que si les deux objets (this et o) appartiennent exactement à la même classe.

Donc, en fonction de ce que vous devez comparer, vous pouvez utiliser l'un ou l'autre.

Si votre logique est: "Un objet est égal à un autre seulement s'ils sont tous les deux de la même classe", vous devriez opter pour les "égaux", ce qui, je pense, est la plupart des cas.

Les deux méthodes ont leurs problèmes.

Si la sous-classe change l'identité, vous devez comparer leurs classes réelles. Sinon, vous violez la propriété symétrique. Par exemple, différents types dePerson s ne doivent pas être considérés comme équivalents, même s'ils portent le même nom.

Cependant, certaines sous-classes ne changent pas d'identité et doivent être utilisées instanceof. Par exemple, si nous avons un tas d' Shapeobjets immuables , alors un Rectangleavec une longueur et une largeur de 1 devrait être égal à l'unitéSquare .

En pratique, je pense que le premier cas est plus vraisemblablement vrai. Habituellement, le sous-classement est une partie fondamentale de votre identité et être exactement comme votre parent sauf que vous pouvez faire une petite chose ne vous rend pas égal.

En fait, instanceof vérifie où un objet appartient à une hiérarchie ou non. ex: l'objet Car appartient à la classe Vehical. Donc "nouvelle instance Car () de Vehical" renvoie true. Et "new Car (). GetClass (). Equals (Vehical.class)" renvoie false, bien que l'objet Car appartienne à la classe Vehical mais il est catégorisé comme un type distinct.