Comment sont liés hashcode() et compareTo()?

Question

J'ai trouvé cette définition de classe:

class TwoTuple28<A,B> implements Comparable { 
    // ... 
    public int hashCode() { 
    int result = 17; 
    result = result * 37 + first.hashCode(); 
    result = result * 37 + second.hashCode(); 
    return result; 
    } 
    public int compareTo(Object o) { 
    if(!(o instanceof TwoTuple28)) throw new ClassCastException(); 
    TwoTuple28 t = (TwoTuple28)o; 
    return (this.hashCode() - t.hashCode() < 0) ? -1 : 
    ((this.hashCode() - t.hashCode() > 0 ? 1 : 0)); 
} 

Pourriez-vous s'il vous plaît me expliquer, pourquoi l'utilisation développeur hashCode() dans compareTo()? Comment sont-ils liés? N'est-ce pas un mauvais moyen?

Answer 1

En bref, c'est une très mauvaise idée. Cela fonctionne en quelque sorte, mais échouera d'une manière qui serait facilement manquée dans les tests. Le but de la comparaison est de dire quand un objet est supérieur, inférieur ou égal à un autre. Lorsque deux objets sont égaux, ils sont considérés comme un doublon pour ConcurrentSkipListMap, TreeMap et TreeSet, ce qui signifie que deux objets avec le même hashCode dans ce cas seraient considérés comme un doublon et ignorés. Quelle est la probabilité que deux objets avec le même hashCode? Si vous avez une collection de dizaines de milliers, vous avez très probablement des doublons même avec un hashCode bien meilleur que celui ci-dessus.

BTW, HashMap et HashSet utilisent maintenant compareTo lorsqu'il y a des collisions et même dans ces collections, une mauvaise comparaison peut signifier que les clés/éléments disparaissent.

La façon la plus sûre d'implémenter cette méthode est de supposer que les premier et second champs sont comparables, sinon vous n'avez pas de base pour les comparer.

---

Sur une note connexe, un puzzle pour vous.

Ecrivez un programme pour imprimer des chaînes de mots qui ont un hashCode() de 0. Vous devriez être capable de générer des milliers en moins de dix secondes.