Sam sobie po części odpowiedziałeś na pytanie.
Metoda hashCode() służy do jednoznacznego porównanywania obiektów. Wygląda tak, a nie inaczej, bo musi wygenerować hasza w taki sposób, żeby dwa 'takie same' obiekty zawsze miały taki sam hasz, ale żeby on się nigdy nie powtórzył dla różnych obiektów.
Dlatego właśnie liczy się to jakoś "dziwacznie", używając "niby to losowych" liczb, często haszy z pól takiego obietku itp...
Koniec końców otrzymany result ma być zawsze taki sam dla tego samego obiektu, i zawsze różny dla dwóch "różnych" (cokolwiek to dla Ciebie w danym kontekście znaczy) obiektów.
Bzdura starszliwa. Za takie coś powtórka bootcampa powinna być.
HashCode musi spełniać jeden główny warunek.
- Jeśli
a.equals(b) to a.hashCode() == b.hashCode()
- Odwrotne wynikanie nie zachodzi. Obiekty różne mogą
zupełnie na luzie mieć ten sam hashCode().
- Zresztą nie dziwne. hashCode to int. Czyli może być różnych hashCodów tyle co intów. Jak by zapewnić różność dla long, float czy np. Stringa?
Zresztą sprawdź.
"DUdek".hashCode()
"Ctdek".hashCode()
Oraclowi się nie udało...
- Podstawowa lekcja z hashCode jest taka, że hashCode postaci:
public int hashCode() {
return 1;
}
Spełnia wszelkie warunki i jest ok. Obiekty z takim hashCodem będą NA PEWNO, poprawnie obsługiwane.
W pewnych sensie jest nawet lepszy od tego wygenerowanego wyżej przykładu z prime i dziwacznymi obliczeniami.
Nie jest jednak idealny...
- Czemu robi się jednak te hocki klocki z liczbami?
Tu trzeba zrozumieć, że hashCode nie zależy od obiektu, tylko od tego jak ten obiekt będzie używany. (Dlatego, tak naprawdę hashCode jest w javie lekko zrypany - bo nie powinien siedzieć w klasie!).
HashCode służy do tego, żeby nieco szybciej odnajdywać obiekt w pewnych strukturach danych (HashSet, HashMap).
Normalanie jeśli chcemy sprawdzić, czy obiekt jest w zbiorze muiselibyśmy robić equals na każdym elemencie. Jeśli w zbiorze będzie np. milion obiektów to takie szukanie, żeby sprawdzić czy np. szpital.contains( a) będzie trochę mało sprawne. Dlatego wymyślono kubełki. HashSet można sobie wyobrazić jako tablicę, z indeksami. Gdzie pod danym indeksem są umieszczone
obiekty z tym samym hashCodem (tak naprawdę to z hashCodem modulo jakaś liczba). Wtedy implementacja contains najpierw sprawdza hashCode obiektu, o który pytamy. Na tej podstawie
wyznacza indeks (adres kubełka). Potem dopiero pyta wszystkich obiektów z danego kubełka (uzywając już equals) - co może być nawet kilkaset razy mniej sprawdzeń equals niż przy robieniu tego w całym zbiorze.
(chyba, że hashSet to stale 1 - wtedy będzie działać tak samo wolno).
- Jak z powyższego widać hashCode powinien być taki, że JEŚLI obiekty wsadzamy do hashMapy czy HashSeta, to w miarę różne obiekty wrzucamy do w miarę różnych kubełków.
Jeśli mamy obiekt z klasy :
class Osoba {
String imie;
String kodPocztowy;
}
To wcale nie wiadomo jaki hashCode będzie idealny!
Jeśli w hashMapie trzymamy wszystkich o nazwisku Nowak, bo gromadzimy bazę danych o Nowakach. To idealny hashCode, będzie tylko używał koduPocztowego, bo dorzucenie tak stale tego samego składnika z nazwiska Nowak nic nie zmieni.
Jeśli natomiast w HashMapie będziemy mieli mieszkańców Koluszek, to możemy sobie kodPocztowy z hashCode wyrzucić.
- Liczenie HashCode powinno być względnie szybkie w porównianiu do equals. HashCode, który liczy się tyle co 50 equalsów zwykle nie ma sensu.
- Tak długo jak obiekt jest w hashSecie lub jest kluczem w HashMapie hashCode nie może się dla obiektu zmienić - inaczej robią się jaja. (Obiekt zostaje
zagubiony w hashMapie).
- Te hocki klocki z
prime, magicznymi liczbami w wygenerowanym hashCode wynikają z tego, że twoje IDE nie wie czy mieszkasz w Koluszkach. Nie wie jak obiekt będzie używany i jakie obiekty będą mieszkać w HashMapie. Robi więc jakiś zamotany hash tak, żeby był on dobry (efektywny) w 99% przypadków.