Discussion :

[maxired]

Bonjour,

tout d'abord désolé pour le titre de ce message, qui sonne comme vu et revu.
Pourtant, je n'ai pas trouvé réponse à ma question.

Il est bien expliqué dans hashcode et equals qu'il faille redéfinir la méthode "hashcode" d'un objet après redéfinition de la méthode "equals" pour respecter le contrat.

Or, il faut que c'est redéfinition se fasse également dans le respect du contrat.
Comme dit dans la Javadoc "Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified".
Définir le hashcode sur la valeur des attributs ne respect donc pas le contrat.

Quel est alors la meilleure méthode à utiliser pour redéfinir la méthode equals d'un objet, afin que deux objets ayant des attributs égaux soit égaux, tout en état standard-compliant ?

Merci.

[tchize_]

tu calcule le hashcode en fonction des valeurs utilisées dans le equals, uniquement.

[CyberChouan]

Exprimé mathématiquement, le contrat doit respecter :

(a.equals(b)) => (a.hashcode() == b.hashcode())

Attention, la réciproque n'est pas nécessairement vraie

[tchize_]

et il est recommandé que la probabilité de a.hashcode()==b.hashcode sous condition (!a.equals(b)) soit la plus faible possible

[maxired]

j'ai bien compris tout cela.

Mais il est également indiqué que le Hashcode d'un objet doit rester le même lors de plusieurs invocation successives...
Or, s'il l'on re-modifie les attributs d'un objet A égal (au sens définis dans ma méthode "equals" surchargé) à un objet B pour le rendre égal à un autre objet C, le hashcode de A doit alors être le même que celui de C, mais également de B si la méthode hashcode avait été initialement appelée.

Le serpent se mort il la queue ou j'ai loupé quelque chose dans l'histoire ?

[tchize_]

si deux objet sont égaux au regard de equals(), alors leur hashcode doivent ausi être égaux (cà c'est pour le contrat equals/hashcode). Il n'est pas stipulé dans hashcode que celui-ci doit rester les même. Il est jsute stipulé que celui-ci doit rester le même *si* les éléments pris en compte par la méthode equals sont restés le mêmes.

[maxired]

Je sais que mon niveau d'anglais est moyen, mais il me semble que "Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified." n'est pas en accord avec ce que tu dis.

[Astartee]

Mais il est également indiqué que le Hashcode d'un objet doit rester le même lors de plusieurs invocation successives...

"Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified."

Le hashcode doit rester le même lors de 2 invocations successives à condition qu'aucune information utilisée par la méthode equals n'ait été modifiée.

Si l'on re-modifie les attributs d'un objet A égal (au sens définis dans ma méthode "equals" surchargé) à un objet B pour le rendre égal à un autre objet C, le hashcode de A doit alors être le même que celui de C, mais également de B si la méthode hashcode avait été initialement appelée.

Tu as un objet A égal (au sens de equals) à un objet B. Son hashcode vaut hash1 et est le même que celui de B.
Tu modifies A pour le rendre égal (au sens de equals) à C. Son hashcode vaut alors hash2 et est le même que celui de C.
Alors certes, si hash1 et hash2 sont différents, le hashcode de A a été modifié. Mais dans ce cas B et C sont différents (au sens de equals) (sinon ils auraient le même hashcode) donc lors de la modification de A tu as forcément du modifier des informations intervenant dans la méthode equals ! La phrase que tu cites est bien respectée...

[maxired]

merci et mea culpa

[tchize_]

et n'oublie pas le bouton