[borrow]

#java #javapomoc
Mam mętlik :P czy metoda equals może mieć w sobie odwołania do metody hashcode żeby sprawdzić czy obiekty są równe? Czy hashcode implementujemy tylko dla kolekcji żeby np nie dodawać duplikatów do Seta?

[l.....k]

@borrow: nie powinna, bo może to skutkować złamaniem kontraktu. jeśli hashcody są różne to equals musi zwrócić false, ale nawet jeśli hashcody są takie same to nie jest powiedziane, że obiekty są takie same. Tak w ogóle to Eclipse czy Intellij oferują generowanie tych metod na podstawie pól, więc moim zdaniem nie ma sensu implementować tego na piechotę o ile nie masz jakiegoś hiper specyficznego przypadku.

[borrow]

@labadzak: czyli kontrakt to jesli ze jesli x.equals(y) TO x.hashcode() = y.hashcode()?

[Waffenek]

@borrow: Najistotniejszą częścią kontraktu equals i hash code jest to że powinny być implementowane razem oraz
gdy
o1.equals(o2)
to
o1.hashCode() == o2.hashCode().

Jednak zwróć uwagę że
o1.hashCode() == o2.hashCode()
nie oznacza że
o1.equals(o2)

Wynika to z tego że funkcja hashCode do każdej możliwej wartości danej klasy przyporządkowuje wartość inta. Int w javie może zawierać wartości od -2147483648 do 2147483647, podczas gdy taki String może w przybliżeniu zawierać dowolną kombinację znaków o

[devfoundry]

Kompilator nie zabroni, ale nie powinno się tego robić, bo te dwie metody powinno się traktować rozdzielnie. Jeśli chcesz wiedzieć więcej to popełniliśmy artykuł na ten temat http://devfoundry.pl/equals-i-hashcode/