Dlaczego wartość klasy wartości jest jego hashCode "nie jest dobrym pomysłem"?

Question

Bardzo ostatni akapit pkt 9 z Effective Java, 2-gie wydanie, J. Bloch mówi, że dla klas wartości jak Integer, String, Date itp przekazujących funkcję dokładnej wartości, które klasa jako the hashCode nie jest dobrym pomysłem.

Tak więc klasa Integer zwracająca value liczby całkowitej, którą reprezentuje jako hashCode, nie jest tak dobra.

Nie jest również hashCode() z String zwracająca wartość całkowitą bezpośrednio odwzorowaną z ogólnej treści, tj. Znaków, które ma instancja String.

Te hashCode() - są wyraźnie zgodne z umową.

Dla mnie wygląda na to, że jest to dobry pomysł, a nie zły - hashCode - różnią się w zależności od wartości różnych obiektów, a te hashCodes są "znormalizowane", zanim zostaną rozłożone na wiadra HashMap/HashSet - tak że hashCode -s z wpisami nie tworzą nastawienie na którym wiadro wpis trafi w

Co ja tu brakuje. - Co sprawia, że ​​mapowanie wartości klasy bezpośrednio do hashCode „zły pomysł"?

TIA

// ===========================

EDIT zobaczyć

pls także komentarze w odpowiedzi na pytanie Steve'a Sieberta.

Answer 1

Co ona mówi, że ci, specyfikacja javadoc powiedzieć dokładnie, jak hashCode jest tworzony. Dzięki temu aplikacje mogą teraz polegać na tym, że to zawsze musi być prawdziwe ... a teraz te implementacje nigdy nie mogą zmienić sposobu generowania kodu haszującego.

To nie znaczy, że nie powinieneś czerpać haszu ze swoich wartości ...tylko nie mów ludziom, jak to zrobić w specyfikacji =)

Answer 2

Interfejs API języka Java właśnie to robi, zwraca liczbę całkowitą.

Integer t = ...; 
t.intValue() == t.hashCode(); // true 

Mam tę samą książkę w pracy. Popatrzę na to w poniedziałek.

Jeśli jesteś naprawdę martwi, wdrożenie FNV-1a hash:

int hash = 0x4C1DF00D; 
    hash = (hash^value) * 0x01000193; 

Answer 3

full quote jest

Wiele klas w bibliotekach platformy Java, takie jak String, Integer i Date, zawierają w swoim podaje dokładną wartość zwróconą przez ich metodę hashCode w zależności od wartości instancji. Zwykle nie jest to dobry pomysł, ponieważ poważnie ogranicza on twoje możliwości: w celu poprawy funkcji skrótu w przyszłych wersjach. Jeśli nie zostanie podana szczegółowa funkcja skrótu, która nie zostanie określona, ​​a wykryta zostanie usterka lub zostanie znaleziona lepsza funkcja skrótu , można zmienić funkcję mieszania w następnej wersji , mając pewność, że żaden klient nie będzie zależał od dokładnych wartości zwracanych przez skrót. funkcjonować.

Podkreślam moją. Książka właśnie stwierdza, że ​​ogólnie uważa się za złą praktykę ujawnienie szczegółów implementacji w specyfikacji. To sprawia, że ​​jest odporny na zmiany.

Fakt, że został wprowadzony jako zwracający dokładną wartość (dla Integer) lub pewną wyliczoną wartość (dla Date i String) nie jest zły.