Discussion :

[Emplyst]

Bon lundi a vous!
Voila en lisant mon livre en ce beau lundi matin dans mon cubicule une question existentielle m'est venu a l'esprit.

Hormis quelques differences tel que la comparaison avec null, quel est l'utilite de faire un .equal alors qu'un .hashCode revient au meme.

Donc la question est equal ou hashCode ou tous deux, la est la question.

(Aportez quelques arguments je suis pas trop fan des axiomes )

[dude]

quel est l'utilite de faire un .equal alors qu'un .hashCode revient au meme.

Faux...
a.equals(b) == true implique a.hashCode() == b.hashCode() mais la réciproque n'est pas vraie.

Et rien n'empeche d'avoir a.equals(b) == false et a.hashCode() == b.hashCode()

[le y@m's]

Si ça peut d'aider dans ton dileme, la doc de la méthode equals() nous dit :

Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.

[yann2]

Bonjour

Trouvé dans la Javadoc de hashCode :

It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hashtables.

[edit]
en gros deux objets dont la méthode equals retourne false peuvent avoir la même valeur pour hashCode
[/edit]

et voilà

[Emplyst]

en gros deux objets dont la méthode equals retourne false peuvent avoir la même valeur pour hashCode

Mouais d'accord mais je vois mal l'interet :]

Bref merci a vous tous, disons que l'aspect le plus interessant dans toutes les reponses recue est ce passage :

"However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hashtables."

Encore une fois merci de la rapidite de vos reponses!

[adiGuba]

Salut,

en gros deux objets dont la méthode equals retourne false peuvent avoir la même valeur pour hashCode

Mouais d'accord mais je vois mal l'interet :]

Tout simplement parce que la méthode hashcode() renvoit un int, et que tu ne peux pas forcément représenter toutes les valeurs possibles...

Les int peuvent prendre les valeurs allant de Integer.MIN_VALUE à Integer.MAX_VALUE (soit -2147483648 à 2147483647), soit un peu plus de quattre milliard de valeurs. Or si tu prend le cas des String, tu as un nombre infini de possibilitée (il suffit d'ajouter une lettre pour créer une nouvelle chaine différente).

Tu ne peux donc pas forcément utiliser un int pour représenter ton objet de manière unique. Et c'est d'autant plus vrai si ton objet contient un grand nombre d'attribut à prendre en compte...

Bref merci a vous tous, disons que l'aspect le plus interessant dans toutes les reponses recue est ce passage :

"However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hashtables."

Disons que ceci est vrai dans le meilleure des mondes... mais il ne faut pas prendre cela pour une réalité ou un objectif à atteindre.

Il faut bien se souvenir que l'unique objectif des hashCode() est d'améliorer le stockage dans les tables de hashage, et en aucun cas de garantir l'égalité de deux objets...

a++

[Emplyst]

Merdi adiGuba cette reponse viens combler ma soif de savoir

[BainE]

bonjour,

je viens de faire quelques tests suite aux posts precedents sur la methode equals, et je viens de m'apercevoir que lorsque je fais

Code :

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

1
2
3
4
5
 
MyObject obj1 = new MyObject();
MyObject obj2 = new MyObject();
 
obj1 == obj2

je ne passe jamais dans la méthode "equals" (que j'ai surchargé bien comme il faut normalement)...
Je croyais que cette méthode opérait comme une surcharge d'operateur ?(comme en C++ par exemple)

Est-ce que je fais une boulette ou est-ce normal ?