Nadpisanie kodu GetHashCode dla mutable objects?

Jeśli masz zmienny obiekt, nie ma sensu nadpisywać metody GetHashCode, ponieważ nie możesz jej użyć. Jest używany na przykład przez Kolekcje Dictionary i HashSet, aby umieścić każdy element w wiadrze. Jeśli zmienisz Obiekt, gdy jest używany jako klucz w kolekcji, kod skrótu nie będzie już pasował do zasobnika, w którym znajduje się obiekt, więc kolekcja nie będzie działać poprawnie i możesz już nigdy go nie znaleźć.

Jeśli chcesz, aby wyszukiwanie nie używało GetHashCode lub Equals metoda klasy, zawsze możesz podać własną implementację IEqualityComparer do użycia zamiast niej podczas tworzenia Dictionary.

Metoda Equals jest przeznaczona do równości wartości, więc nie jest źle zaimplementować ją w ten sposób.

Wow, to właściwie kilka pytań w jednym : -). Więc jeden po drugim:

Przytoczono, że wartość GetHashCode nigdy nie powinna się zmieniać w ciągu życia obiektu. Jak to działa, jeśli pola, na których się opiera, są zmienne?

Ta powszechna rada jest przeznaczona dla Przypadku, Gdy chcesz użyć obiektu jako klucza w HashTable / słowniku itp. . Hashtable zwykle wymagają, aby hash nie zmieniał się, ponieważ używają go do decydowania o tym, jak przechowywać & Odzyskaj klucz. Jeśli hash ulegnie zmianie, tablica HashTable prawdopodobnie nie będzie już znajdować Twojego obiektu.

Aby przytoczyć dokumenty interfejsu Javy Map :

Uwaga: Należy zachować szczególną ostrożność, jeśli zmienne obiekty są używane jako klucze map. Zachowanie mapy nie jest określone, jeśli wartość obiektu zostanie zmieniona w sposób wpływający na porównania równości, podczas gdy obiekt jest kluczem na mapie.

Ogólnie rzecz biorąc, używanie dowolnego rodzaju mutowalnego obiektu jest złym pomysłem jako klucz w tabeli hash: nie jest nawet jasne, co powinno się stać, jeśli klucz zmieni się po dodaniu go do tabeli hash. Czy tabela hash powinna zwracać przechowywany obiekt za pomocą starego klucza, nowego klucza lub obu?

Tak więc prawdziwa rada brzmi: używaj tylko niezmiennych obiektów jako kluczy i upewnij się, że ich hashcode nigdy się nie zmienia (co zwykle jest automatyczne, jeśli obiekt jest niezmienny).

Również co, jeśli chcę, aby wyszukiwania słownika itp były oparte na równości odniesienia nie Moje przesadne równo?

Cóż, znajdź implementację słownika, która tak działa. Ale słowniki biblioteki standardowej używają hashcode & Equals i nie ma sposobu, aby to zmienić.

Przede wszystkim nadpisuję Equals dla łatwości testowania jednostkowego mojego kodu serializacyjnego, który zakładam serializing i deserializing (do XML w moim przypadku) zabija równość odniesienia, więc chcę się upewnić, że przynajmniej jest poprawna przez równość wartości. Czy to zła praktyka, aby obejść Równi w tym przypadku?

Nie, uznałbym to za całkowicie akceptowalne. Nie należy jednak używać takich obiektów jak klucze w słowniku/hashtable, ponieważ można je zmieniać. Patrz wyżej.

Tematem przewodnim jest jak najlepiej identyfikować obiekty. Wspominasz serializację/deserializację, która jest ważna, ponieważ integralność odniesienia jest tracona w tym procesie.

Krótka odpowiedź jest taka, że obiekty powinny być jednoznacznie identyfikowane przez najmniejszy zestaw niezmiennych pól, które mogą być używane do tego celu. Są to pola, których powinieneś użyć, gdy nadpisujesz GetHashCode i Equals.

Do testowania jest całkiem sensowne definiowanie dowolnych twierdzeń need, zazwyczaj nie są one definiowane na samym typie, ale raczej jako metody użytkowe w zestawie testowym. Może TestSuite.AssertEquals (MyClass, MyClass) ?

Zwróć uwagę, że GetHashCode i Equals powinny działać razem. GetHashCode powinien zwracać tę samą wartość dla dwóch obiektów, jeśli są sobie równe. Equals powinien zwracać true wtedy i tylko wtedy, gdy dwa obiekty mają ten sam kod skrótu. (Zauważ, że możliwe, że dwa obiekty nie są sobie równe, ale mogą zwrócić ten sam kod skrótu). Jest mnóstwo strona, która zajmuje się tym tematem head-on, wystarczy google away.

Nie wiem, czy C# jest względnym noobem, ale w Javie, jeśli nadpisujesz equals (), musisz również nadpisać hashCode (), aby utrzymać kontrakt między nimi (i vice-versa)... A java też ma ten sam catch 22; W zasadzie wymuszanie używania pól niezmiennych... Ale jest to problem tylko dla klas, które są używane jako klucz hashowy, a Java ma alternatywne implementacje dla wszystkich kolekcji opartych na hashach... które może nie tak szybko, ale skutecznie pozwalają na użycie mutowalnego obiektu jako klucz... po prostu (zazwyczaj) marszczy brwi jako "kiepski projekt".

I czuję potrzebę zwrócenia uwagi, że ten podstawowy problem jest ponadczasowy... Jest tu od kiedy Adam był chłopcem.

Pracowałem nad kodem fortran, który jest starszy ode mnie (mam 36 lat), który psuje się po zmianie nazwy użytkownika (np. gdy dziewczyna wychodzi za mąż lub się rozwiedzie ;-) ... Tak więc jest inżynieria, przyjęte rozwiązanie było: GetHashCode "metoda" zapamiętuje wcześniej obliczony hashCode, przelicza hashCode (tzn. wirtualny znacznik isDirty) i jeśli pola kluczowe zostały zmienione, zwraca null. Powoduje to, że cache usunie "brudnego" użytkownika (przez wywołanie innego GetPreviousHashCode), a następnie Cache zwróci null, powodując ponowne odczytanie z bazy danych. Ciekawy i wartościowy hack; nawet jeśli sam tak powiem; -)

Wymienię zmienność (pożądaną tylko w narożnych przypadkach) na dostęp O(1) (pożądaną we wszystkich przypadkach). Witamy w engineering; krainie świadomych kompromis.

Zdrówko. Keith.