interface
6
  • Najlepsze
  • Wszystkie komentarze
n.....y
n.....y
@interface: W sumie to o co chodzi... Nie czaje... Ja bym wolał aby equals nie przyjmował typu Object
0
b.....7
b.....7
@nie_tuzinkowy: dlaczego?
0
n.....y
n.....y
@boo007: Bo mozesz porpwnac np Person o z Order o i te klasy dziedzicza po equals...
0
b.....7
b.....7
@nie_tuzinkowy: ale jak napiszesz np.
Person a = new Person();
Object b = a;
to co powinno zwrócić a.Equals(b)?
Moim zdaniem było by z tym więcej problemów.
0
n.....y
n.....y
@boo007: Moim zdaniem nie powinno sie wywolac wtedy a.equals(b) juz na poziomie kompilacji...
0
b.....7
b.....7
@nie_tuzinkowy: wtedy masz problem z np. HashSet-em, jeśli chcesz przechowywać elementy różnych typów. Wszystkie implementacje wykorzystują metodę Equals do sprawdzania kolizji. Pewnie dało by się to obejść, ale trochę za dużo zabawy moim zdaniem.
0
interface
HashSet-em, jeśli chcesz przechowywać elementy różnych typów. Wszystkie implementacje wykorzystują metodę Equals do sprawdzania kolizji


@boo007: hashset jak nazwa wskazuje używa hashCode jako "wartosci" obiektu. gdyby hashSet uzywal equals do porownania obiektow to big O operacji add byloby O(n), bo musialbys za kazdym razem porownac nowy obiekt do istniejacych w hashsecie, hashSet add ma O(1), contains też ma O(1) a przy equals byloby best scanario O(1) worst scenario O(n).
0
b.....7
b.....7
@interface: równe hashCody nie dają gwarancji, że obiekty są równe, dlatego zawsze jest używana metoda Equals do upewnienia się, że oba obiekty są rowne.
0