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.

[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 ?

[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 !