Discussion :

[jojodu31]

Bonjour à tous,
je me posais une petite question.
On est d'accord que tous les objets que l'on utilise en clé d'une Map doivent redéfinir les méthode equals(..) et hashCode().

Maintenant si j'ai un object C en clé de ma Map, et que celui ci contient deux attributs de type AttributA et AttributB
AttributA et AttributB ne redéfinissent pas les 2 méthodes en question.
Est-ce que ça va changer quelque chose chose si je redéfini les 2 méthodes equals et hashCode ?

En effet des mon equals et mon hashcode je vais appeler les même méthodes sur AttributA et AttributB qui eux n'ont rien redéfini... d'où ma question => est-ce que ça va changer grand chose niveau perf de redéfnir les méthodes dans mon objet C ?

Merci d'avance

[deathness]

Le mieux est encore que tu fasses le test.

En théorie oui ça change, l'exécution du equals a bien évidemment un cout, et donc redéfinir ces méthodes a théoriquement un impact, positif ou négatif.

En pratique, je pense pas qu'on peut obtenir un gain significatif en surchargeant ces méthodes.

[adiGuba]

Salut,

d'où ma question => est-ce que ça va changer grand chose niveau perf de redéfnir les méthodes dans mon objet C ?

Ce n'est pas uniquement uen question de performance. Il faut impérativement redéfinir ces méthodes pour que la Map retrouve ses petits. Si tu ne le fais pas tu risques de "perdre" des éléments.

Si tes attributs ne définissent ni hashCode ni equals, tu devras implémenter cela toi même pour gérer l'unicité de tes clef.


a++

PS : Par curiosité quel est ce type clef que tu utilises ?

[jojodu31]

ok, en fait j'utilise un objet métier (pas le choix) dans une table de 10000 éléments (dans le pire cas).

En fait je posais la question car mes attributs sont encore des objets métier et du coup ils héritent eux aussi d'autres classe qui n'implémentent toujours pas equals() ni hashcode()... je vais donc devoir me farcir toutes les implémentations jusqu'au plus haut niveau ?

[thelvin]

... Ou alors tu l'implémente uniquement dans ton objet de plus haut niveau, celui qui sert de clé, et tu y implémente comment calculer le hashCode() et le equals() de tout ce qu'il peut contenir.

Mais en principe, oui, on redéfinit hashCode() et equals() pour tout le monde, dès lors qu'il y a une chance qu'on s'en serve. C'est quelque chose à penser pour la moindre création de nouvelle classe de données.

[Rei Ichido]

D'une manière générale, toujours redéfinir equals et hashCode. Ça évitera les mauvaises surprises le jour où quelqu'un voudra faire une HashMap contenant ces objets.

Maintenant, si ta ClasseC a des attributs de ClasseA et ClasseB, tu n'as pas forcément à redéfinir equals et hashCode sur ces deux classes : ça dépend entièrement de si les attributs en question sont utilisés pour la fonction equals de classeC.

Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
public classeC {
  private ClasseA attributA;
  private ClasseB attributB;
  private int id;
 
  [...]
 
  public boolean equals(Object other) {
     if (! other instanceof ClasseA) return false;
     if (other == this) return true;
     ClasseA otherA = (ClasseA) other;
     return otherA.id == this.id;
  }
 
  public int hashCode() {
      return this.id;
  }
}

Dans cet exemple, pas la peine pour faire "fonctionner" equals et hashcode de redéfinir ceux de ClasseB et ClasseC. Il n'empêche que ça serait quand même franchement souhaitable !

[jojodu31]

Mais en principe, oui, on redéfinit hashCode() et equals() pour tout le monde, dès lors qu'il y a une chance qu'on s'en serve. C'est quelque chose à penser pour la moindre création de nouvelle classe de données.

tout à fait d'accord...mais tu sais ce que c'est t'arrives sur le projet et bien souvent tu reprends l'existant...

je vais essayer de faire implémenter ces méthodes partout, y a du boulot


Si je peux me permettre il faut utiliser le getClass() plutôt que:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

! other instanceof ClasseA

[thelvin]

tout à fait d'accord...mais tu sais ce que c'est t'arrives sur le projet et bien souvent tu reprends l'existant...

Ben, ça s'appelle devoir corriger les merdes du code existant.
Ou alors, peut-être que c'est une aberration de chercher à utiliser les classes existantes comme des clés, c'est possible aussi.

Si je peux me permettre il faut utiliser le getClass() plutôt que:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

! other instanceof ClasseA

Tu peux certainement te le permettre, mais je suis curieux de savoir pourquoi il faudrait ça.
Tu as un exemple, et une explication d'en quoi c'est mieux ?

[jojodu31]

Ou alors, peut-être que c'est une aberration de chercher à utiliser les classes existantes comme des clés, c'est possible aussi.

arg c'est l'existant ça aussi... Mais je vais faire mon possible remettre les choses à plat.

Tu peux certainement te le permettre, mais je suis curieux de savoir pourquoi il faudrait ça.
Tu as un exemple, et une explication d'en quoi c'est mieux ?

La méthode equals() doit remplir le contrat suivant (extrait de la Javadoc):

The equals method implements an equivalence relation on non-null object references:

It is reflexive: for any non-null reference value x, x.equals(x) should return true.
It is symmetric: for any non-null reference values x and y, x.equals(y) should return true if and only if y.equals(x) returns true.
It is transitive: for any non-null reference values x, y, and z, if x.equals(y) returns true and y.equals(z) returns true, then x.equals(z) should return true.
It is consistent: for any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified.
For any non-null reference value x, x.equals(null) should return false.

SI tu utilises le instanceOf la relation n'est plus symétrique.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
//1
if( obj.getClass() != this.getClass() ) return false; 
 
//2
if(!(obj instanceof MaClasse)) return false;

Le code //1 (avec le getClass) assure que si l'appel est fait avec une classe fille de MaClasse on retournera faux.

Le code //2 (avec instanceOf) peut nous permettre de renvoyer true si l'appel est fait avec une classe fille.
On aura donc:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
maClasseFille.equals(maClasseMere); // => true
 
maClasseMere.equals(maClasseFille); // => false

La relation n'est pas symétrique.

Voilou

[thelvin]

Si les instances d'une classe fille n'étaient jamais égales à des instances d'une classe mère, le polymorphisme serait une vaste blague.

Soit Etudiant une classe, et EtudiantInfirmier une classe fille de Etudiant, tout ce qui est un EtudiantInfirmier est aussi un Etudiant.
Par conséquent, ou bien deux Etudiant ne peuvent jamais être égaux, ou bien il existe des couples (Etudiant, EtudiantInfirmier) qui sont égaux, ou bien la conception de ces classes est mauvaise.

La relation n'est symétrique que si chaque implémentation de sous-classe tient à cœur de la garder symétrique, et elles ne sont pas obligées de le faire. Cela fait partie des choses qui ne se font pas automagiquement.

Pour donner un exemple réél, si une ArrayList et une LinkedList ne pouvaient jamais être égales, la notion d'égalité ne leur serviraient à rien du tout.

[tchize_]

Si tu utilise tes objets métier comme clé, il y a un point qui, je pense, n'a pas été soulevé. Une fois rentré comme clé, ton objet métier ne peux plus changer. Autrement dit, tout futur appel à equals ou hashcode sur cet objet retournera toujours la même valeur.


Donc si ton objet métier n'as pas un état constant, tu peux oublier tout de suite cette usage.

Et vu ta complexité d'implémenter equals/hashcode, je suis sur qu'au moins un de ces attribut ou sous attribut a un état variable avec le temps!

[jojodu31]

Si les instances d'une classe fille n'étaient jamais égales à des instances d'une classe mère, le polymorphisme serait une vaste blague.

Si tu me trouves un exemple dans l'API Java je veux bien voir... De plus ça me parait tout à fait logique qu'une classe mère ne soit pas égale à une fille.

Soit Etudiant une classe, et EtudiantInfirmier une classe fille de Etudiant, tout ce qui est un EtudiantInfirmier est aussi un Etudiant.
Par conséquent, ou bien deux Etudiant ne peuvent jamais être égaux, ou bien il existe des couples (Etudiant, EtudiantInfirmier) qui sont égaux, ou bien la conception de ces classes est mauvaise.

2 EtudiantInfirmier peuvent être égaux sans soucis. Si Etudiant est une interface ou classe abstraite alors pas de soucis non plus tu peux utiliser le instanceOf. Si ce n'est pas le cas, en effet la conception est à revoir ainsi que le polymorphisme en lui même...

La relation n'est symétrique que si chaque implémentation de sous-classe tient à cœur de la garder symétrique, et elles ne sont pas obligées de le faire. Cela fait partie des choses qui ne se font pas automagiquement.

Non la symétrie est obligatoire (voir Javadoc), sauf si tu veux des comportements imprévisibles, exemple: On a donc une égalité non symétrique:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
A a =new A();
B b = new B();
a.equals(b) => true
b.equals(a) => false.

List<A> list = new ArrayList<A>();
list.add(a);

list.contains(b) => suivant l'implémentation on aura true, false ou une runtime error... (cf "Effictive Java").

Pour donner un exemple réél, si une ArrayList et une LinkedList ne pouvaient jamais être égales, la notion d'égalité ne leur serviraient à rien du tout.

ArrayList et LinkedList ne sont pas mère/fille mais soeur et l'implémentation du equals est faite dans la classe abstraite AbstractList. Le instanceOf est correct ici, la symétrie est préservée.

[jojodu31]

Si tu utilise tes objets métier comme clé, il y a un point qui, je pense, n'a pas été soulevé. Une fois rentré comme clé, ton objet métier ne peux plus changer. Autrement dit, tout futur appel à equals ou hashcode sur cet objet retournera toujours la même valeur.

tout à fait, en fait c'est assez compliqué mais cela ne posera pas de problèmes (c'est bien la seule chose qui ne pose pas de problèmes )...

[thelvin]

Si tu me trouves un exemple dans l'API Java je veux bien voir... De plus ça me parait tout à fait logique qu'une classe mère ne soit pas égale à une fille.

java.util.Date et java.sql.Date, java.sql.TimeStamp et et java.sql.Time, par exemple.
S'il te paraît à la fois logique qu'une classe mère et une classe fille aient une relation "est-un" et qu'elle ne puissent jamais être égales, je ne vois pas ce que je peux faire de plus. Il y a quelque chose dans la notion d'héritage qui te perturbe très fortement.

2 EtudiantInfirmier peuvent être égaux sans soucis. Si Etudiant est une interface ou classe abstraite alors pas de soucis non plus tu peux utiliser le instanceOf. Si ce n'est pas le cas, en effet la conception est à revoir ainsi que le polymorphisme en lui même...

Il n'y a aucune raison pour que la non-instanciabilité intervienne en quoi que ce soit dans ces questions. Si c'est logique pour des classes abstraites ou des interfaces, c'est logique pour toute relation surtype/soustype.

Non la symétrie est obligatoire (voir Javadoc), sauf si tu veux des comportements imprévisibles, exemple: On a donc une égalité non symétrique:

Elle est annoncée obligatoire, et les choses ne marcheront pas bien si ce n'est pas respecté.
Mais c'est à la charge de chaque implémenteur de respecter cette contrainte, ce n'est pas quelque chose que l'implémenteur de la classe de plus haut niveau, doit ou peut imposer au reste du monde.

ArrayList et LinkedList ne sont pas mère/fille mais soeur et l'implémentation du equals est faite dans la classe abstraite AbstractList. Le instanceOf est correct ici, la symétrie est préservée.

Si elles sont classes sœurs, c'est qu'elles ont une classe mère commune, donc le raisonnement est le même... Passons.
Rien au monde ne m'empêche de sous-classer une ArrayList pour en faire une UnmodifiableArrayList. Dans ce cas, la spec de List.equals() exige que UnmodifiableArrayList soit égale à n'importe quelle List qui a les même éléments dans le même ordre, ce qui inclut n'importe quelle ArrayList. Si une comparaison de classe exacte était utilisée quelque part plutôt qu'instanceof, cela serait impossible à faire.

[tchize_]

jojodu31: tu dois utiliser de préférence instanceOf dans ton equals, sinon tu casse tes possibilités d'héritage.

Tu peux me dire Etudiant ne peux pas être égal a EtudiantInfirmier donc je check les .class.

Moi je te dis, il est normal que Etudiant puisse être égal à EtudiantProxy, qui fait un proxy sur un autre Etudiant, donc je ne peux pas utiliser les .class.

C'est à EtudiantInfirmier SI il redéfinit equals(Object) de ce charger de la symmétrie de equals, pas au parent! Ainsi, EtudiantInfirmire pourrait avoir comme code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
public boolean equals(Object o){
  if (o instanceof EtudiantIfirmer){
     // comparer deux EtudiantInfirmier
  } else if (o instanceof Etudiant)
     return super.equals(o); // comparer deux étudiant
}

C'est d'autant plus important de ne pas vérifier les .class directement que si tu utilise des outils comme hibernate (qui enrobe tes objet data), spring (qui peux enrober avec aspectj), jrebel (qui fait du proxying automatique), tu n'aura pas le choix: dans 99% des cas t'aura une sous-class générée dynamiquement et donc ton test machin.class==truc.class échouera et tu reviendra au controle de base: seul seront égaux les objets étant la même instance, ce qui n'est pas le but recherché.

[deathness]

Disons qu'il n'a jamais du être confronté à faire des choses de ce genre. Cela arrive surtout lorsque l'on se base sur un framework que cela peur poser problème. Mais dans ce cas le equals est presque toujours a bannir.

[tchize_]

Mais dans ce cas le equals est presque toujours a bannir.

Je ne vois pas pourquoi.

[jojodu31]

Elle est annoncée obligatoire, et les choses ne marcheront pas bien si ce n'est pas respecté.
Mais c'est à la charge de chaque implémenteur de respecter cette contrainte

c'est pas faux, après tout si on veut faire du code qui donne des résultats aléatoires why not

Disons qu'il n'a jamais du être confronté à faire des choses de ce genre. Cela arrive surtout lorsque l'on se base sur un framework que cela peur poser problème. Mais dans ce cas le equals est presque toujours a bannir.

exact deathness mais merci pour ces réponses tout n'est jamais si simple en Java

[thelvin]

c'est pas faux, après tout si on veut faire du code qui donne des résultats aléatoires why not

Attention, les résultats sont pas plus aléatoires de la bonne manière que de la manière que tu recommandes.
Redéfinir equals(), c'est toujours possible, donc les implémenteurs peuvent toujours faire n'importe quoi. Sur ce point-là, il y a égalité entre les deux méthodes : la tienne essaie d'éviter un problème, mais c'est impossible donc elle échoue. La bonne reconnaît l'impossibilité et accepte les conséquences.

Avec la bonne méthode, si les implémenteurs ne jouent pas le jeu, on peut toujours éviter les bugs en refusant d'utiliser les classes bugguées. On peut penser que quelqu'un d'autre proposera la même chose sans bug.

Avec ta méthode, il devient impossible de faire des sous-classes qui puissent exposer des propriétés égales mais qui ne cassent pas la symétrie de equals(). Les implémenteurs ne peuvent pas faire les choses correctement, ça ne dépend pas d'eux. Autrement dit, la seule solution est de ne jamais se permettre de créer d'autres sous-classes que celles que tu avais prévues dès le départ. C'est une méthode de conception acceptable, mais c'est un cas spécifique, ce n'est pas le cas général. Et donc la méthode recommandée n'est pas recommandable en général.

exact deathness mais merci pour ces réponses tout n'est jamais si simple en Java

Cela n'est pas spécifique à Java, mais aux notions d'héritage et de relation d'équivalence cohérente. On est pas obligé de s'en servir si on trouve ça trop compliqué.
Mais pas de relation d'équivalence => Pas de Set et pas de Map.

De toute façon, ta vision des choses ne rendait rien plus simple, c'est juste que tu y étais à l'aise parce que c'est toi qui l'avait construite. Pour un regard extérieur c'est kif-kif.