Forum Java

SylvainITIN2004

public int hashCode(){
   if (this.pseudonyme != null){
     return this.pseudonyme.hashCode(); /*1*/
   }
   else {
     return super.hashCode(); /*2*/
   }
}

Pour ce que j'ai compris de hashCode. Vous me direz si je me trompe:
c'est un tableau paire valeur qui permet d'indexer les objets selon un entier qui renvoie vers la référence de l'objet qui lui est associé. et Ceci si nous ne redéfinissons pas la méthode. Nous redéfinissons notre HashCode pour qu' elle n'indexe plus selon les références des objets mais plutot sur les pseudonymes. Cette manipulation a pour particularité d'accélérer les recherches par pseudonyme. Voila ce que j'ai compris avec mes mots (un peu simpliste j'avoue).

/*1*/: Est ce que c'est cette ligne qui donne l'intruction d'indexer selon les pseudonyme? Je ne comprend pas trop l'implémentation. Pourriez vous dévelloppez un peu.

/*2*/: juste pour assurer ma compréhension. super fait référence à la super-classe java.lang.Objet et cette ligne renvoie le code de Hash par défaut.

J'ai voulu jeter un oeil sur la classe java.lang.objet et j'ai bien trouvé les différentes méthodes que nous redéfinissons. Seulement pour hashCode rien n'est implémenter nous avons seulement: public native int hashCode(); et du blabla. Qu'est ce que cela signifie? Ou puis-je trouver l'implémentation.

Enfin dernière question: Dans votre livre (2eme édition) page 88 vous dites "la relation d'égalité définie entre deux objets doit-être alors réflexive, commutative et transitive." Pourriez vous commentez ses trois termes qui ne veulent malheureusement rien dire pour moi. J'ai chercher un peu sur le net mais je tombe sur des explications mathématiques. Avez-vous des explications simple et grossière, histoire de comprendre l'idée générale. Merci
---
Vive JAVA!!!

Manu

> public int hashCode(){
>    if (this.pseudonyme != null){
>      return this.pseudonyme.hashCode(); /*1*/
>    }
>    else {
>      return super.hashCode(); /*2*/
>    }
> }
>
> Pour ce que j'ai compris de hashCode. Vous me direz si je me trompe:
> c'est un tableau paire valeur qui permet d'indexer les objets selon un entier qui renvoie vers la référence de l'objet qui lui est associé. et Ceci si nous ne redéfinissons pas la méthode.
> Nous redéfinissons notre HashCode pour qu' elle n'indexe plus selon les références des objets mais plutot sur les pseudonymes.
> Cette manipulation a pour particularité d'accélérer les recherches par pseudonyme. Voila ce que j'ai compris avec mes mots (un peu simpliste j'avoue).

Vous avez compris le principe à part que ce sont les classes HashSet, HashMap... de java.util, qui mémorisent un ensemble d'entrées (clé, valeur) dans une sorte de tableau interne optimisé grâce au hashCode de chaque clé. Ces classes sont décrites pages 120 et 121, et réutilisées dans la suite de l'ouvrage.


> /*1*/: Est ce que c'est cette ligne qui donne l'intruction d'indexer selon les pseudonyme? Je ne comprend pas trop l'implémentation. Pourriez vous dévelloppez un peu.

Comme on veut "indexer" sur les pseudonymes, il faut renvoyer un hashCode associé au pseudonyme. Au lieu de calculer nous-même une valeur en fonction du pseudonyme, on demande ce service à la méthode hashCode de la classe String qui est redéfinie pour calculer un hashCode en fonction des caractères d'une chaîne.
Par ailleurs, n'oubliez pas qu'on doit redéfinir la méthode hashCode en tenant compte surtout de la façon dont equals a été redéfinie elle-même, sachant que si deux objets de classe Utilisateur sont égaux par la méthodes equals, ils doivent avoir le même hashCode.
Si cette relation n'est pas vérifiée, il est possible que vous ne puissiez plus retrouver un utilisateur particulier dans un ensemble de classe HashSet ou HashMap qui contient des objets de classe Utilisateur, car ces classes utilisent la méthode hashCode *et* la méthode equals pour les recherches d'objet (voir aussi l'aparté page 140).
La relation inverse "si deux objets de classe Utilisateur ont le même hashCode, ils doivent être égaux par la méthodes equals" n'a pas besoin d'être vérifiée.


> /*2*/: juste pour assurer ma compréhension. super fait référence à la super-classe java.lang.Objet et cette ligne renvoie le code de Hash par défaut.
>
> J'ai voulu jeter un oeil sur la classe java.lang.objet et j'ai bien trouvé les différentes méthodes que nous redéfinissons. Seulement pour hashCode rien n'est implémenter nous avons seulement: public native int hashCode(); et du blabla. Qu'est ce que cela signifie? Ou puis-je trouver l'implémentation.

C'est plus ou moins l'adresse mémoire de l'objet qui est forcément différente d'un objet à l'autre. Une méthode native est une méthode implémentée en C ou en C++ et compilée dans une DLL (librairie dynamique) à laquelle la JVM fait appel. Cette DLL est différente d'un système à l'autre contrairement aux fichiers .class qui sont eux portables.
Si vous voulez les sources complets de toute la JVM et de toutes les classes de la bibliothèque standard (code C, C++ et Java), ils sont disponibles à http://wwws.sun.com/software/java2/download.html


> Enfin dernière question: Dans votre livre (2eme édition) page 88 vous dites "la relation d'égalité définie entre deux objets doit-être alors réflexive, commutative et transitive."
> Pourriez vous commentez ses trois termes qui ne veulent malheureusement rien dire pour moi.

La définition offerte par la javadoc de equals (voir http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#equals(java.lang.Object) ) n'est-elle pas assez claire ?
Pour en revenir sur les fondements mathématiques de la réflexivité, de la commutativité et de la transitivité, vous pouvez regarder aussi sur Wikipedia à http://fr.wikipedia.org/wiki/Relation_binaire

[Message modifié le 27/10/2005]
---
Manu (moderator/modérateur)

SylvainITIN2004

C marrant ca été mon premier reflexe d'aller sur wikipédia.
Après plusieurs lectures j'ai cru comprendre l'essentiel. Mon esprit matheux est maleheureusement en vacances depuis trop longtemps. :s
Faut avouer que ce genre de vocabulaire est soutenu. ;-)

Merci pour vos explications.
Arrèter moi si vous pensez que mes interrogations deviennent trop précises. Certaines fois on peut accepter les choses et ne pas perdre de temps à les comprendre. J'ai tendance à aimer les détails car sinon j'ai du mal à réutiliser efficacement.
---
Vive JAVA!!!

Manu

> Arrêtez moi si vous pensez que mes interrogations deviennent trop précises.

Pas de problème, du moment que ça vous éclaire vous et d'autres lecteurs.
Les méthodes equals et hashCode de la classe Object sont une des grosses difficultés dans l'apprentissage de Java, car il faut bien aborder la classe fondamentale Object pour commencer à étudier la bibliothèque Java. Du coup, faut-il faire l'impasse sur ces méthodes alors qu'elle servent surtout au bon fonctionnement des classes de collection, étudiées à la fin du même chapitre ? Mais si on fait cette impasse, la classe Utilisateur serait incomplète et il faudrait la corriger ensuite, ce que je n'ai préféré pas faire pour éviter des renvois qui perdent le lecteur...
Ca n'est pas simple aussi d'imaginer des cas de programmes où il serait possible qu'on rencontre deux instances de la classe Utilisateur pour un même utilisateur (ne serait-ce pas plutôt un bug ?), alors qu'a priori chaque utilisateur étant unique, on pourrait penser qu'il n'y pas de raison que ça puisse arriver !
Après avoir vu plusieurs exemples d'utilisation des classes du forum dans la suite, j'espère que vous en comprendrez l'intérêt.

En me basant sur l'idée que "les mauvaises habitudes se perdent difficilement", j'ai préféré proposer le plus tôt possible les bonnes pratiques de programmation en Java dans ce livre (c'est le cas pour les packages et l'encapsulation abordés très tôt, pour ces méthodes equals et hashCode...), quitte à ce que certaines solutions restent un peu obscures au moment où elles sont présentées. Ce genre de pédagogie provoque inévitablement des questions chez certains lecteurs comme vous, mais c'est plutôt sain de votre part ;-)
---
Manu (moderator/modérateur)