Java Type d'arrivée equals(): instanceof vs getClass()

Question

D'abord, je suis pas demander la différence entre eux.

J'ai une idée à l'esprit et je voudrais plus le cerveau de vérifier, ce qui semble en mesure de prendre (la plupart) les avantages de l'approche utilisant à la fois.

En bref, equals() en Java ressemble généralement à ce sujet.

public boolean equals(Object other) { 
    if (other == null) return false; 
    if (this == other) return true; 
    if (this and other is not of the same type) return false 
    // then actual equals checking 
} 

Le problème réside dans le « cela et d'autres n'est pas du même type » vérifier.

Un flot de gens préfèrent utiliser if (! (other instanceof MyClass)), qui ont l'inconvénient de

• facilement conduire à la suite asymétrique. Si autre est une sous-classe de MyClass et a substituée equals(), a.equals(b) et b.equals(a) ne sera pas la même
• Pour éviter cela, nous devons éviter la classe des enfants de surcharger equals(), en le déclarant finale

L'autre flux de gens préfèrent utiliser if (getClass() != other.getClass()), qui a le défaut de

• Violant principe de substitution Liskov. Une classe enfant de MyClass devrait être en mesure d'utiliser à la place de MyClass.
• Par conséquent, a.equals(b) sera faux si a est de MyClass tandis que b est d'une classe enfant de MyClass, même les attributs internes sont identiques.

---

J'ai une idée à l'esprit, je veux que les gens vérifier.

Cette approche devrait

1. Si une classe enfant substituée equals(), les résultats doivent encore être symétrique

2. Une classe enfant pourra toujours être utilisé comme type de parent (dans l'aspect de equals() et equals n'est pas redéfinie bien sûr)

   public class Parent { 
       @Override 
       public boolean equals(Object other) { 
        if (other == null) return false; 
        if (this == other) return true; 
        if (!(other instanceof Parent)) return false; 
        try { 
         if (other.getClass().getMethod("equals", Object.class).getDeclaringClass() != Parent.class) { 
          return other.equals(this); 
         } 
        } catch(Exception neverHappen){} 
   
        // do actual checking 
       } 
   } 
   

L'idée principale est, si this rencontré un objet Parent, mais cet objet de equals() non déclarée dans Parent (à savoir cet objet est une classe enfant, avec equals() substituée, je vais déléguer l'invocation equals à l'objet de classe enfant (ou peut simplement renvoyer false).

Y at-il défaut d'utiliser cette approche que j'ai oublié? (Je suppose que la perte de performance sera une préoccupation, mais je crois que l'appel de getClass().method("equals").getDeclaringClass() devrait être assez bon marché?

Answer 1

Y a-t-il un inconvénient à utiliser cette approche?

Cela ne fonctionnerait pas. La méthode à appeler est déterminée au moment de la compilation. Le polymorphisme s'applique uniquement à la référence avant . et non après.

other.equals(this); // always calls equals(Object); as `other` is an Object. 

également

other.getClass().getMethod("equals", /* method with no args */).getDeclaringClass(); 

Je suppose que vous vouliez. GetMethod other.getClass() ("égale", Parent.class), mais vous devez attraper NoSuchMethodException

Je crois call de getClass(). method ("equals"). getDeclaringClass() devrait être assez bon marché?

Pas dans ma sélection. C'est plus rapide que de lire quelque chose à partir du disque, mais vous ne voudriez pas le faire très souvent. Enfin, vous devez vous assurer que a.equals (b) ==> b.equals (a) et si a.equals (b) alors a.hashCode() == b.hashCode() qui est difficile à faire est a et b sont différents types.

Answer 2

Comme indiqué dans les commentaires, si la classe enfant fait super.equals(..), vous obtiendrez un stackoverflow. Pour éviter cela, vous finirez par réécrire tous les parents equals(..) dans chaque enfant, ce qui est encore pire design.

D'une certaine manière, cela dépend du comment/pourquoi vous avez implémenté l'héritage en premier lieu. Un enfant devrait-il être comparable à un parent? Est-ce que la comparaison a du sens? (édité)

Si vous remplacez égal, alors vous ne respectez pas LSP, par définition. Si un enfant a plus de paramètres (ce qui signifie qu'il surpasse la méthode equals), alors il ne doit pas être égal à son parent, et c'est pourquoi nous pouvons comparer en utilisant getClass() != other.getClass() dans le parent. Si vous souhaitez utiliser la classe equals() de votre classe parent (vous n'avez donc pas à tout réécrire), vous ne finirez pas par stackoverflowing; equals() serait juste faux, car ils n'étaient pas censés être égaux.

Et si un enfant est comparable à son parent? Si vous respectez LSP, l'enfant ne devrait pas avoir un equals() différent de celui de son parent (ie: égal ne devrait pas être remplacé), je suppose. Donc le cas asymétrique ne devrait pas exister.

Si un enfant est comparable à son parent, mais a plus de paramètres? C'est maintenant votre conception, ne respectant pas LSP, donc c'est à vous de voir ce que cela signifie dans votre contexte et d'agir en conséquence.

---

EDIT: @Adrian oui, "ne symmmetry logique" était mauvaise formulation, je aurais dû dire "ce que le sens comparaison?".

Pour exemple, si vous comparez deux classes d'enfants avec getClass() et ils utilisent super avec aussi getClass() il retourne vrai (le test sera redondant, car this.getClass() et other.getClass() aura toujours les mêmes valeurs, chez l'enfant et le parent). Mais comme je l'ai dit, si vous comparez un enfant et un parent, ce sera faux (et je pense que c'est normal s'ils ont des paramètres différents).

Pourquoi utiliser final uniquement sur égal à avec instance de? Vous l'avez dit, à cause de l'asymétrie possible, alors qu'il n'est pas possible d'être assymétrique avec l'héritage en utilisant getClass(), donc inutile de le rendre final dans ce cas.

En note, si vous utilisez getClass(), alors plusieurs enfants du même parent ne seront pas comparables (toujours retourner faux). Si vous utilisez instanceof, ils le peuvent, mais s'ils le font, aucun enfant ne doit surcharger equals() pour risquer de rompre la symétrie. (Je pense que vous avez obtenu cela, mais je me demandais quand choisir insteanceof au lieu de getClass() si c'est si problématique).