[Java] equals() = bizarre

equals() = bizarre [Java] - Programmation

Marsh Posté le 14-03-2002 à 22:42:10    

J'ai fait un petit programme de test pour vérifier que la méthode contains() d'un hashset fonctionne bien avec une classe que j'ai créé dans laquelle je redéfinis la méthode equals(). Eh bien, ça ne fonctionne pas et je ne comprends pas pourquoi.
 
Voilà le test :
 
class setUnicite {
 
    public static void main(String [] args) {
        Set s = new HashSet();
        String d = new String("toto" );
        Etat e1 = new Etat(d,true,false);
        Etat e2 = new Etat(d,true,false);
        Etat e3 = new Etat("toto",true,false);        
        s.add(e1);
        System.out.println("e1.equals(e1) = " + e1.equals(e1));        
        System.out.println("s.contains(e1) = " + s.contains(e1));
        System.out.println("e1.equals(e2) = " + e1.equals(e2));        
        System.out.println("s.contains(e2) = " + s.contains(e2));
        System.out.println("e1.equals(e3) = " + e1.equals(e3));        
        System.out.println("s.contains(e3) = " + s.contains(e3));
    }
     
}
 
Et voilà le résultat :
 
[root@localhost test]# java setUnicite
e1.equals(e1) = true
s.contains(e1) = true
e1.equals(e2) = true
s.contains(e2) = false
e1.equals(e3) = true
s.contains(e3) = false
 
Et pourtant là où ça devient magique, c'est quand on regarde la specif de contains() :  
 
Returns true if this set contains the specified element. More formally, returns true if and only if this set contains an element e such that (o==null ? e==null : o.equals(e)).
 
Alors si quelqu'un a une idée sur le phénomène, merci d'avance.

Reply

Marsh Posté le 14-03-2002 à 22:42:10   

Reply

Marsh Posté le 14-03-2002 à 22:48:03    

t'as redéfini le hashcode() ??


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 14-03-2002 à 23:00:30    

Ok ça vient de là :) En fait, j'avais essayé de la modifier mais j'avais mis hashcode() et non pas hashCode()... Alalala heureusement que personne ne programme des logiciels de gestion du trafic aérien en Java :)
 
Bon est-ce que quelqu'un a une idée pour associer un entier unique à une chaîne de caractère ? J'avais bien pensé à un truc du genre le code ascii de chaque caractère concaténé pour faire un nombre mais ça me parait super lourd comme méthode.

Reply

Marsh Posté le 14-03-2002 à 23:07:57    

t'as pas besoin de te faire chier avec ca !
la seule condition pour la méthode hashcode c'est qu'elle renvoie la même valeur pour  2 objets dans la méthode renvoie vrai.
 
Pour optimiser les algo de hashage (utiliser par les classes HashMap,etc ..), il faut essayer d'élargir le plus possible la plage de valeur que pourras renvoyer la méthode Hashcode.
 
Un truc tout simple, c'est de renvoyer la somme des hashcode des attributs dont tu teste l'égalité dans le equals. Mais attention, le hashcode peu finir par être assez gourmand avec cette méthode.
 
Tu peux par exemple de renvoyer que le hashcode de ta chaine de caractère. Ce sera nettement suffisant !


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 14-03-2002 à 23:10:37    

exo_ a écrit a écrit :

En fait, j'avais essayé de la modifier mais j'avais mis hashcode() et non pas hashCode()...  




 
y a un truc qui est dommage en Java, c'est que tu ne sois pas obligé de déclarer lorsque tu surcharge une méthode.
un truc du style  
 
public extending int hashcode () { ... }
 
Ca éviterait ce genre d'erreur difficilement visibles


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 14-03-2002 à 23:18:54    

Ok ça marche si je renvoie le hashcode de ma chaîne. Mais en fait dans ma petite tête, je m'étais dit que : "Deux objets String distincts, même si ils ont la même valeur n'ont pas le même hashcode parce que le hashcode grosso modo c'est la valeur du pointeur (ou plutôt de l'identificateur) de l'instance." Mais apparemment ce n'est pas du tout le cas. Beaucoup merci en tout cas :)

Reply

Marsh Posté le 14-03-2002 à 23:24:02    

c'est la valeur de base. C'est ce que Object renvoie par défaut, parce qu'il ne sait pas quoi renvoyer d'autre ;)
 
C'est pour ca que dès que tu redéfinies equals, il faut redéfinir hashcode. Sinon ca marche plus ...


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 15-03-2002 à 16:52:28    

exo_ a écrit a écrit :

Bon est-ce que quelqu'un a une idée pour associer un entier unique à une chaîne de caractère ? J'avais bien pensé à un truc du genre le code ascii de chaque caractère concaténé pour faire un nombre mais ça me parait super lourd comme méthode.  




 
Elle te plait pas, la methode hashCode par defaut de String ? Si tu veux en refaire une similaire, voila son algo:
 
Returns a hashcode for this string. The hashcode for a String object is computed as  
 
 s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]
 
using int arithmetic, where s[i] is the ith character of the string, n is the length of the string, and ^ indicates exponentiation. (The hash value of the empty string is zero.)

Reply

Marsh Posté le 15-03-2002 à 16:58:15    

exo_ a écrit a écrit :

Ok ça vient de là :) En fait, j'avais essayé de la modifier mais j'avais mis hashcode() et non pas hashCode()... Alalala heureusement que personne ne programme des logiciels de gestion du trafic aérien en Java :)




 
D'où tiens tu cette information? Il y a des logiciels de gestion de traffic aérien en Java ... Chez EuroControl nottament ...


---------------
Just because you feel good does not make you right
Reply

Marsh Posté le 18-03-2002 à 21:05:12    

Au temps pour moi. Mais est-ce que Java est vraiment fréquemment utilisé pour coder des applications qui touchent à des domaines critiques ? Pour ma part, j'aurais plutôt imaginer que l'on utilisait des vieux machins éprouvés par le temps comme le C ou alors des trucs plus blindés comme Ada.

Reply

Marsh Posté le 18-03-2002 à 21:05:12   

Reply

Marsh Posté le 19-03-2002 à 13:36:36    

OK pour Ada plus blindé, mais pour C plus éprouvé, c'est à côté : le problème n'est pas le risque d'erreurs dans les compilateurs, mais dans le code applicatif lui-même, et de ce point de vue, Java est nettement moins risqué que C ou même C++.

Reply

Marsh Posté le 19-03-2002 à 13:42:11    

BifaceMcLeOD a écrit a écrit :

OK pour Ada plus blindé, mais pour C plus éprouvé, c'est à côté : le problème n'est pas le risque d'erreurs dans les compilateurs, mais dans le code applicatif lui-même, et de ce point de vue, Java est nettement moins risqué que C ou même C++.  




 
exactement!


---------------
Just because you feel good does not make you right
Reply

Marsh Posté le 19-03-2002 à 23:33:08    

yes. rien vaut un bon système d'exception.
et pour ca, java et ada sont blindés !!


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 19-03-2002 à 23:38:08    

BifaceMcLeOD a écrit a écrit :

OK pour Ada plus blindé, mais pour C plus éprouvé, c'est à côté : le problème n'est pas le risque d'erreurs dans les compilateurs, mais dans le code applicatif lui-même, et de ce point de vue, Java est nettement moins risqué que C ou même C++.  




 
Le dormeur vient de se reveiller!!!
 
En intercontrat?

Reply

Marsh Posté le 20-03-2002 à 09:21:33    

- Renaud - a écrit a écrit :

 
 
Le dormeur vient de se reveiller!!!
 
En intercontrat?  




 
 
Consultant on the beach? J'ai connu ça aussi  :lol:


---------------
Just because you feel good does not make you right
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed