Override de equals()

Comment ferriez-vous pour override la méthode equals(Obj o) pour qu'elle compare 2 Points d'une Classe Point ayant pour constructeur

Code:

---

1 2 3 4

public Point() { x = 0; y = 0; }

---

...les X et Y sont lu à partir d'un fichier de X,Y à l'aide de la Classe Scanner

Code:

---

1 2 3 4 5

public void lire(Scanner reader)? { this.x = reader.nextInt(); this.y = reader.nextInt();   }

---

Voici ma tentative d'override:

Code:

---

1 2 3 4 5 6 7 8

public boolean equals(Point p) { if((x == ((Point)p).x && y == ((Point)p).y)) { return true; }else { return false; }   }

---

salut,

On ne voit pas tous le code mais je dirai basiquement :

Code:

---

1 2 3 4

@Override public boolean equals(Point p) { return this.x == p.x && this.y == p.y }

---

Equals prend un Object en paramètre, il faut d'abord valider la nullité et le type, puis caster et enfin comparer les données des objets.

Aussi, equals doit s'accompagner d'un hashcode, ça fait partie de son contrat.

Il y a une véritable guerre de religion sur equals :aie:
le paramètre est un objet et on va tester si on peut d'abord effectuer le transtypage (cast)
deux options s'affrontent:
- ceux qui comparent la classe courante à celle de l'objet passé en paramètre (au moyen de getClass())
- ceux qui veulent passer par un instanceof pour tester au préalable les capacités de cet objet
je fais partie de cette deuxième secte :lol:

Citation:

---

Envoyé par professeur shadoko

- ceux qui comparent la classe courante à celle de l'objet passé en paramètre (au moyen de getClass())
- ceux qui veulent passer par un instanceof pour tester au préalable les capacités de cet objet

---

La différence entre instanceof et getclass est que getclass nécessite de tester la nullité au préalable, ce n'est pas le cas de instanceof, qui renvoie false en cas de null.

Il y a une autre différence entre getClass() et instanceof : ce dernier acceptera les classes filles, ce qui peut mettre à mal la symétrie requise par les spécifications de equals().

Sinon l'implémentation de hashCode() n'est pas requise lorsqu'on redéfini equals(). C'est l'inverse 😉

Oui, enfin, en plus des spécifications générales de equals(), il y a aussi les spécifications que lui donnent la classe qui le définit. Après tout, qu'est-ce que l'égalité entre deux objets, c'est le travail de la classe de le dire, donc de le décider.

java.util.List, par exemple, spécifie que toute implémentation de List a le devoir d'avoir une méthode equals() qui considère comme égal un objet :
- seulement si il implémente List (et peu importe sa classe véritable)
- avec size() qui renvoie le même nombre
- dont les éléments aux mêmes indexes, renvoient true si on les passe par Objects.equals(). (Soit ils sont tous les deux null, soit aucun n'est null et le premier faisant equals() sur l'autre donne true.)

Pour une telle définition, getClass() n'est pas adapté, il faut instanceof

... Et nous avons là un exemple typique de polymorphisme. Si un type B est sous-type d'un type A, il doit offrir un comportement compatible avec le comportement du type A. Logique donc que tout objet de A puisse être comparé avec B et avoir ses chances de renvoyer true si l'objet de type B a un contenu équivalent à l'objet de type A, et ce peu importe sa classe. D'une certaine manière, on peut imaginer que B, en tant que sous-type contienne des choses en plus que A. Et donc qu'il y a renoncement à tenir compte de ces choses en plus lors d'une comparaison avec un autre objet. Mais en même temps c'est ça, le polymorphisme : se comporter comme on l'attend du type générique auquel on se conforme.

Je n'ai pas dit que getClass() était plus adapté 😉
Juste que le comportement est différent...

Les besoins peuvent être varié et avec l'héritage il peut parfois être compliqué de gérer tout cela en respectant toutes les règles de equals().
Voir même impossible si l'on ne maîtrise pas toutes la hiérarchie des classes...

Citation:

---

Envoyé par adiGuba

Il y a une autre différence entre getClass() et instanceof : ce dernier acceptera les classes filles, ce qui peut mettre à mal la symétrie requise par les spécifications de equals().

---

Pas si on respecte le LSP.

Citation:

---

Envoyé par adiGuba

Sinon l'implémentation de hashCode() n'est pas requise lorsqu'on redéfini equals(). C'est l'inverse 😉

---

Si on ne veut pas de comportement indéterminé avec l'API collection, et certainement avec un tas de lib, il faut les 2.

Citation:

---

Envoyé par yildiz-online

Pas si on respecte le LSP.

---

LSP ?

Citation:

---

Envoyé par yildiz-online

Si on ne veut pas de comportement indéterminé avec l'API collection, et certainement avec un tas de lib, il faut les 2.

---

Tout à fait !

Probablement Liskov Substitution Principle. En gros, la même chose que ce que je disais. Il y a un nom pour ça.

Citation:

---

Envoyé par thelvin

Probablement Liskov Substitution Principle. En gros, la même chose que ce que je disais. Il y a un nom pour ça.

---

C'est bien ça oui.

J'ai du mal à voir en quoi ce concept pourrait résoudre le problème du equals().

Prenons la classe Point, et imaginons lui une sous-classe Pixel avec une propriété supplémentaire (couleur).

Si Point::equals() utilise instanceof, comment définir Pixel::equals() afin qu'il prenne en compte la couleur tout en respectant les règles du equals() ??
Selon les cas on perd soit la symétrie soit la transitivité...

Et de manière plus globale le choix du instanceof ou getClass() dépend du type de comparaison que l'on souhaite :

• instanceof permet d'accepter les classes filles dans la comparaison (mais du coup elle ne devrait pas redéfinir equals() ou changer son comportement)
• getClass() permet de rejeter les classes filles, et donc de s'assurer de tout problème en limitant fortement les types à comparer.

Dans ce cas le LSP n'est pas respecté, et pour cause, conceptuellement, un pixel a une position et des informations de couleur(et d'autre éventuellement suivant le contexte), c'est donc un object qui contient un instance de point et une instance de couleur, un héritage ne serait pas approprié.

Si on ne peut pas rajouter d'attribut ni modifier le comportement... que reste-t-il à l'héritage pour respecter le LSP ?

Tu peux ajouter tous les attributs et changer tous les comportements internes que tu veux, tant que ce qui est exposé à l'extérieur n'est pas impacté, c'est la base du principe d'encapsulation.
(et donc pas de changement de visibilité non plus ni de checked exception en plus/moins).

Un exemple serait une classe de cache, dans le parent, tu aurais la policy de cleaning, la taille maximum, la liste des documents cachés... et tu pourrais avoir des classes enfants avec un file cache, un cache DB, un cache memory...

Tous ces enfants auront des comportements et des données internes totalement différents, mais les données/méthodes exposées ne sont pas impactée, ça respecte le lsp.

Citation:

---

Envoyé par adiGuba

Et de manière plus globale le choix du instanceof ou getClass() dépend du type de comparaison que l'on souhaite :

• instanceof permet d'accepter les classes filles dans la comparaison (mais du coup elle ne devrait pas redéfinir equals() ou changer son comportement)
• getClass() permet de rejeter les classes filles, et donc de s'assurer de tout problème en limitant fortement les types à comparer.

---

Comme quoi il faut toujours réfléchir à ce que l'on veut;)
Ceci dit je me suis arraché les quelques cheveux qui me reste en écrivant un framework qui se trouvait à gérer des classes mandataires passées à des codes comprenant ce genre de getClass(). C'est pas facile d'écrire des composants qui pourraient être utilisés par d'autres :aie: