Redéfinition de equals

bonjour

je suis à redéfinir equals
voici donc mon code,
Code:

1 2 3 4 5 6 7 8 public boolean equals(Object name) { if (this.nom.equals(((Humain)name).nom)) System.out.println("Identique"); else System.out.println("Non identique"); return; }
est-ce une bonne méthode? si oui comment faire pour retourner soit le mot identique ou non identique lorsque je ferai la comparaison.
si non comment puis-je le faire

merci!

Bonjour,
Code:

1 2 3 4 5 6 7 public boolean equals(Object o) { Humain temp=(Humain)o; if (this.nom.equals(temp.nom)) return true; return false; }
equals retourne un boolean, vrai si les deux objets sont égaux, faux sinon.

Quelques améliorations :

Code:

1
2
3
4
5
6
7
8
9
10
11
 
public boolean equals(Object o)
{
  try {
     Humain temp=(Humain)o;
     if (this.nom != null) return this.nom.equals(temp.nom);
  } catch (ClassCastException e) { //on peut aussi laisser remonter l'exception ....
 
  }
  return false;
}

Citation:
Envoyé par Ricky81
Quelques améliorations :
Code:

1 2 3 4 5 6 7 8 9 10 11 public boolean equals(Object o) { try { Humain temp=(Humain)o; if (this.nom != null) return this.nom.equals(temp.nom); } catch (ClassCastException e) { //on peut aussi laisser remonter l'exception .... } return false; }
1) Ne jamais remonter une exception de type ClassCast dans un equals.
Si c'est pas une classe de type Humain, tu retourne false.

2) Ne pas oublier d'implementer la méthode qui va de paire avec equals (hashcode) pour mieux distribuer les objets dans les Hashtable, HashMap et autres

Citation:

Envoyé par vbrabant

2) Ne pas oublier d'implementer la méthode qui va de paire avec equals (hashcode) pour mieux distribuer les objets dans les Hashtable, HashMap et autres

Sans oublier la méthode compareTo (interface Comparable) pour les tris dans les collections :P

Citation:

Envoyé par Ricky81

Sans oublier la méthode compareTo (interface Comparable) pour les tris dans les collections :P

Mais non il ne me semble pas. Si l'on surcharge la méthode equals il faut redéfinir également hashcode mais compareTo ce n'est pas du tout obligé! Cette méthode est définie lorsque la classe implémente Comparable mais autrement pas.

Une petite question concernant hashCode().

Citation:

Envoyé par Javadoc Object.hashCode()

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)

quel est l'interet de redefinir hashCode(), pourquoi ne pas utliser celle de Object qui doit fonctionner tout le temps ?

je n'ai pas tester et je n'ai jamais utiliser volontairement hashcode(), je ne l'ai d'ailleurs jamais redéfini... (c'est grave docteur ? ? ?)

je pose la question parce qu'au programme des certifications java :

Citation:

Envoyé par Sun Certified Programmer for the Java 2 Platform, Standard Edition 5.0

Distinguish between correct and incorrect overrides of corresponding hashCode and equals methods, and explain the difference between == and the equals method.

A noter aussi que tu peux ajouter une petite optimisation au début de ta méthode equals:
Code:

1 2 3 4 5 6 7 public boolean equals(Object o) { if(this==o) return true; //la suite }
Dans la pratique, c'est très courant. ;)

Citation:

Envoyé par @ldehan

Une petite question concernant hashCode().

quel est l'interet de redefinir hashCode(), pourquoi ne pas utliser celle de Object qui doit fonctionner tout le temps ?

je n'ai pas tester et je n'ai jamais utiliser volontairement hashcode(), je ne l'ai d'ailleurs jamais redéfini... (c'est grave docteur ? ? ?)

je pose la question parce qu'au programme des certifications java :

hashCode() est utilisé par des algos dans certaines classes (HashSet, HashMap). si hashCode() est implémenté correctement, ça améliore les performances de ces classes.

[edit]Et en effet, il y a des questions dessus lors de la certif.

Au fait, dans vos exemples de equals, vous n'avez pas testé si le paramètre est null

Salut,

Citation:

Envoyé par @ldehan

quel est l'interet de redefinir hashCode(), pourquoi ne pas utliser celle de Object qui doit fonctionner tout le temps ?

La méthode hashCode() de Object n'est pas forcément la bonne, car elle considère que tous les objets sont différents, et le hashCode() renvoyé est donc toujours différents.

Maintenant, il faut bien comprendre que l'objectif du hashCode est d'améliorer la recherche d'élément dans un arbre (c-a-d les différentes implémentations de Map). Pour simplifier (et parce que je ne connais pas le mechanisme en détail), lorsque tu ajoutes un couple clef/valeur dans une Map, le couple est stocké dans des tableaux internes selon le hashCode de la clef. Ainsi lorsque tu rechercheras la valeur associée à la clef, il accèdera uniquement à une partie des données (pas besoin de comparer toutes les clef de la Map).

La méthode hashCode() doit normalement vérifier la condition suivante :

Citation:

Si deux objets sont egaux, alors leurs hashCode() sont également égaux (mais l'inverse n'est pas vrai).

Et pour la classe Object, deux objet sont égaux uniquement si ils représentent la même instance. Par exemple le code suivant renvoit toujours false :
Code:

1 2 3 4 Object o1 = new Object(); Object o2 = new Object(); System.out.println( "equals() : " + o1.equals(o2) ); System.out.println( "hashCode() : " + o1.hashcode() + ", " + o2.hashcode() );
Tout simplement parce que la méthode equals() de Object est codé comme ceci :
Code:

1 2 3 public boolean equals(Object obj) { return (this == obj); }
donc il n'y a pas de problème à renvoyer un hashCode différent...

Or pour des objets un peu plus évolués, la méthode equals() se base sur le contenu de ces objets, et deux instances différents du même objet peuvent être égaux, par exemple si tu compares ces deux chaines tu obtiendras true et le même hashCode, ce qui est normal puisque bien qu'il s'agissent de deux instances différentes, elles représentent la même valeur :
Code:

1 2 3 4 Object o1 = new String("hello"); Object o2 = new String("hello"); System.out.println( "equals() : " + o1.equals(o2) ); System.out.println( "hashCode() : " + o1.hashcode() + ", " + o2.hashcode() );
Tout simplement parce que la classe String a redéfini ces deux méthodes de manière concordante...

Citation:

Envoyé par @ldehan

je n'ai pas tester et je n'ai jamais utiliser volontairement hashcode(), je ne l'ai d'ailleurs jamais redéfini... (c'est grave docteur ? ? ?)

Non... enfin ca dépend...

Si tu n'utilises pas tes objets en tant que clef dans des Map, ce n'est pas vraiment utile (mais c'est toujours mieux de le faire).

Sinon tu peux te retrouver avec des résultats incohérent et des éléments innaccessible dans tes Map...

Généralement dans hashCode() je retourne la somme de tous les hashCode() des champs que j'utilise dans ma méthode equals(), ce qui donne quelque chose comme cela :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 public class MaClasse { private int field1; private String field2; private Date field3; // ignoré par equals() et hashcode() @Override public boolean equals(Object obj) { if (this==obj) { return true; // c'est la même instance // inutile de continuer c'est forcément égal ! } // on vérifie qu'il s'agissent bien de la même instance if (obj instanceof MaClasse) { MaClasse c = (MaClasse) obj; // on compare les différents champs : return // comparaison de type primaire : (this.field1==c.field1) && ( // comparaison d'objet : this.field2==c.field2 // comparaison de référence (au cas où) || (this.field2!=null && this.field2.equals(c.field2)) // comparaison des objets ); } // sinon on retourne false; return false; } @Override public int hashCode() { return this.field1 + this.field2.hashCode(); } }
a++

Merci d'avoir pris le temps de me repondre en détails, c'est déja beaucoup plus clair.

mais j'aurais cependant une question quant à ton implémentation

Citation:

Envoyé par adiGuba

Généralement dans hashCode() je retourne la somme de tous les hashCode() des champs que j'utilise dans ma méthode equals()

pourquoi ne pas utilisé le résultat de hashCode() de l'objet ? genre :

Code:

super.hashCode() + this.field1 + this.field2.hashCode()

Citation:

Envoyé par @ldehan

pourquoi ne pas utilisé le résultat de hashCode() de l'objet ? genre :

Code:

super.hashCode() + this.field1 + this.field2.hashCode()

Parce que super.hashCode() appelle la méthode hashCode() de Object, qui renvoit une valeur différente pour chaque instance. Or si mes deux objets sont egaux hashCode() doit renvoyer la même valeur...

a++

Citation:

Envoyé par adiGuba

Généralement dans hashCode() je retourne la somme de tous les hashCode() des champs que j'utilise dans ma méthode equals(), ce qui donne quelque chose comme cela :

Et si vous etes des flemmards comme moi (ou des gens qui cherchent à écrire le moins de code possible), c'est déjà tout fait dans commons-lang:
http://jakarta.apache.org/commons/la...deBuilder.html

Citation:

Envoyé par denisC

Et si vous etes des flemmards comme moi (ou des gens qui cherchent à écrire le moins de code possible), c'est déjà tout fait dans commons-lang:
http://jakarta.apache.org/commons/la...deBuilder.html

Jakarta est vraiment formidable :D

Citation:

Envoyé par adiGuba

Parce que super.hashCode() appelle la méthode hashCode() de Object, qui renvoit une valeur différente pour chaque instance. Or si mes deux objets sont egaux hashCode() doit renvoyer la même valeur...

a++

Oui oui, autant pour moi. je viens de relire la javadoc avec les explications que tu m'as fourni. j'ai tout compris et j'y penserais dorénavent.

Merci encore de toutes ces précisions ;)

Citation:

Envoyé par Pollux

Mais non il ne me semble pas. Si l'on surcharge la méthode equals il faut redéfinir également hashcode mais compareTo ce n'est pas du tout obligé! Cette méthode est définie lorsque la classe implémente Comparable mais autrement pas.

Mea culpa pour la mauvaise compréhension de mon message.
Je voulais simplement ajouter que de la définir pouvait s'avérer utile :wink:

Eric