Discussion :

[Compassio]

Bonjour.

Je sais que lorsque l'on compare deux objets avec le symbole ==, cela ne vaut VRAI que lorsque les deux objets sont en fait la même instance. Je sais aussi que la méthode equals dans la classe Object fait par défaut un == si elle n'est pas redéfinie, du coup, si je veux que equals compare mes objets par rapport à leurs attributs, je dois la redéfinir.

Mais là où je bloque, c'est avec les Strings. J'ai le code suivant :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
class Main {
 
    public static void main(String[] args) {
        String s = new String("Blabla");
        String v = new String("Blabla");
 
        System.out.println(s.hashCode());
        System.out.println(v.hashCode());
 
        if (s == v)
            System.out.println("s et v sont égales");
        if (s.equals(v))
            System.out.println("s et v sont égales sémantiquement");
 
 
 
    }
}

Ce code m'affiche en terminal :

Code :

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

1
2
3
4
 
1992251584
1992251584
s et v sont égales sémantiquement

Je ne comprends pas pourquoi il rentre dans le second if. J'ai utiliser la déclaration new String, donc s et v ne sont pas les mêmes instances. Du coup, je ne rentre pas dans le premier if, mais je ne devrai pas non plus rentrer dans le second, vu que equals fait par défaut un ==.
Pouvez-vous m'expliquer ?

merci

[adiGuba]

Salut,

Je sais que lorsque l'on compare deux objets avec le symbole ==, cela ne vaut VRAI que lorsque les deux objets sont en fait la même instance.

Plus précisément, == compare la valeur des références.
Ainsi pour deux références a et b, a==b est vrai seulement si a et b pointent sur la même instance en mémoire.

vu que equals fait par défaut un ==.

La classe String redéfinie equals()/hashCode() de manière approprié.
Et heureusement sinon ce serait complètement inutile...


a++

[Compassio]

Merci pour ta réponse

Donc la référence est bien unique pour chaque instance ? Si deux objets sont strictement identique, ça veut dire qu'ils pointent vers la même adresse mémoire ?

Référence et pointeurs sont synonymes ? Je n'ai jamais rencontré la notion de pointeur auparavant.

[joel.drigo]

La notion de pointeur représente une entité (variable par exemple, ou notation) qui contient (ou représente) la référence d'une zone mémoire dans les langages qui ont cette notion (C, pascal...). En Java, pas de notion de pointeur. Mais les objets sont bien stockés en mémoire et ont donc une référence unique par instance. La référence en Java est une sorte d'adresse dans un référentiel interne à la JVM, propre à Java. On dit qu'une variable pointe vers un objet, mais c'est une façon de dire que la variable a pour valeur la référence de cet objet.

Si deux objets sont strictement identique, ça veut dire qu'ils pointent vers la même adresse mémoire ?

Les objets ne pointent pas. Et deux objets ne peuvent pas être identiques : c'est un objet unique dans ce cas. Ce sont les valeurs dans les variables qu'on compare par ==. Ces valeurs peuvent être identiques et, dans ce cas, les 2 variables pointent bien vers le même objet (contiennent la même référence d'objet).

Attention à hashcode() :

• ce n'est pas forcément une référence
• si 2 objets vérifiant equals() doivent avoir le même hashcode, 2 objets ne vérifiant pas equals() peuvent avoir le même hashcode

[Compassio]

Merci à toi.

J'en profite pour rebondir sur un dernier point, je ne comprends pas très bien à quoi sert cette fonction hashcode().

Ce que je sais, c'est qu'elle permet de donner un sorte de code à un objet, en effectuant des calculs en fonction de ses attributs. Mais j'ai lu que le hashcode n'était pas unique pour chaque objet, et que certains objets peuvent partager le même hashcode, du coup je ne comprend pas l'intérêt, peux-tu m'expliquer s'il te plaît ?

[tchize_]

le hashcode sert à toutes les classes qui ont besoin de pouvoir organiser grossièrement des objets. Comme deux objets ayant un hashcode différent ne peuvent pas être equals, ça permet de faire des comparaison rapides qui éliminent une grande partie des collisions. Il faut toujours ensuite passer dans equals pour bien vérifier lorsque les hascode sont identique, mais si ils sont différents on n'en pas besoin. Exemple, un HashSet de 5000 entrées. On veut savoir si l'objet X existe dans le Set. On prend X.hashCode(), on regarde à l'entrée correspondante dans la table de hashage: c'est vide. On peux retourner false avec une seule comparaison au lieu de 5000. On a deux entrée à ce hash: on les compares tous les deux à X via equals: on sait si X est dans le Set avec seulement 3 comparaisons au lieu de 5000.