hashCode() - explain the magic

Mógłby ktoś wytłumaczyć, co się dzieje przy nadpisywaniu metody hashCode(). Wiem, że jesli się nadpisze metodę equals() to trzeba również nadpisać hashCode(), aby był zachowany "kontrakt" : a.hashCode()==b.hashCode() Jeśli jej nie nadpiszemy, to zwróci ona różne wartości nawet dla obiektów, które pod względem przechowywanych wartości są równe.
Generalnie chodzi mi o wytłumaczenie, co dzieje się tutaj i dlaczego tak

@Override
	public int hashCode() {
		final int prime = 31;
		int result = 1;
		result = prime * result + ((name == null) ? 0 : name.hashCode());
		long temp;
		temp = Double.doubleToLongBits(price);
		result = prime * result + (int) (temp ^ (temp >>> 32));
		return result;

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.

Poprawna implementacja metody jest ważna chociażby ze względu na kolekcje, które mogą przechowywać obiekty danej klasy, a do uszeregowania obiektów potrzebują metody hashCode() właśnie.
HashSet.class na przykład...
Generalnie - jeśli obiekt1.equals(obiekt2) == true, to obiekt1.hashCode() == obiekt2.hashCode() - powinno być zachowane zawsze.

Wiem, wiem. Ale właśnie jak to się liczy? Majac notepada albo kartkę papieru byłbyś w stanie to napisać samemu?

Ja gdy mam jakies proste DTOsy korzystam z metody pomoczniczej Generalnie nie musi to byś jakas skomplikowana metoda, ważne żeby spełniała założenia (jak jest equals to hashcode ten sam) no i żeby nie było że każdy obiekt ma ten sam hashCode ;]

TakiTamPiekarz napisał(a):

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.

1. Jeśli a.equals(b) to a.hashCode() == b.hashCode()
2. Odwrotne wynikanie nie zachodzi. Obiekty różne mogą zupełnie na luzie mieć ten sam hashCode().
3. 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...

1. 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...

1. 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).

1. 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ć.

1. 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.
2. 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).
3. 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.

Pytanie jest dobre i ciekawe, z tym że całkiem niezłe odpowiedzi na nie są już na wielu stronach, tutorialach i w książkach.

Kilka przykładów:
https://www.baeldung.com/java-hashcode
https://dzone.com/articles/working-with-hashcode-and-equals-in-java
https://www.sitepoint.com/how-to-implement-javas-hashcode-correctly/
https://www.mkyong.com/java/java-how-to-overrides-equals-and-hashcode/
http://tutorials.jenkov.com/java-collections/hashcode-equals.html
https://javarevisited.blogspot.com/2011/10/override-hashcode-in-java-example.html

Generalnie, cała filozofia sprowadza się do tego, aby wyszukiwanie wartości w HashMapach działało jak najbardziej optymalnie. JVM pod spodem układa wartości z tym samym hash codem w kubełkach (bucketach) i podczas porównywania wartości, najpierw lecimy po hashCode(), a potem po equals(). Mógłbyś w hashCode() równie dobrze dać "return 1"; i też by działało, tylko byłoby to nieoptymalne rozwiązanie. Jeżeli chcesz poznać więcej detali i dowiedzieć się, dlaczego są tam takie liczby, a nie inne, to polecam książkę "Effective Java" (polski tytuł: "Java. Efektywne Programowanie"). Jest to tam opisane na kilku stronach.