Dlaczego ważne jest, aby przesłonić GetHashCode, gdy metoda Equals jest przesłonięta?

Biorąc pod uwagę następującą klasę

public class Foo
{
    public int FooId { get; set; }
    public string FooName { get; set; }

    public override bool Equals(object obj)
    {
        Foo fooItem = obj as Foo;

        if (fooItem == null) 
        {
           return false;
        }

        return fooItem.FooId == this.FooId;
    }

    public override int GetHashCode()
    {
        // Which is preferred?

        return base.GetHashCode();

        //return this.FooId.GetHashCode();
    }
}

Przesłoniłem Equalsmetodę, ponieważ Fooreprezentują wiersz dla Footabeli s. Jaka jest preferowana metoda zastępowania GetHashCode?

Dlaczego warto to zmienić GetHashCode?

Tak, ważne jest, aby twój przedmiot był używany jako klucz w słowniku, HashSet<T>itp. - ponieważ jest on używany (w przypadku braku niestandardowego IEqualityComparer<T>) do grupowania przedmiotów w wiadra. Jeśli kod skrótu dla dwóch elementów nie pasuje, nigdy nie można ich uznać za równe ( Equals po prostu nigdy nie zostanie wywołany).

Metoda GetHashCode () powinna odzwierciedlać Equalslogikę; zasady są następujące:

• jeśli dwie rzeczy są równe ( Equals(...) == true), muszą zwrócić tę samą wartość dlaGetHashCode()
• jeśli GetHashCode()jest równy, nie musi być taki sam; jest to kolizja i Equalszostanie wezwana, aby sprawdzić, czy jest to prawdziwa równość, czy nie.

W tym przypadku wygląda na to, że „ return FooId;” jest odpowiednią GetHashCode()implementacją. Jeśli testujesz wiele właściwości, często łączy się je za pomocą kodu jak poniżej, aby zmniejszyć kolizje po przekątnej (tj. Tak, że new Foo(3,5)ma inny kod skrótu niż new Foo(5,3)):

unchecked // only needed if you're compiling with arithmetic checks enabled
{ // (the default compiler behaviour is *disabled*, so most folks won't need this)
    int hash = 13;
    hash = (hash * 7) + field1.GetHashCode();
    hash = (hash * 7) + field2.GetHashCode();
    ...
    return hash;
}

Och - dla wygody możesz również rozważyć dostarczenie ==i !=operatorów podczas nadpisywania Equalsi GetHashCode.

Wykazanie tego, co się dzieje, kiedy się to źle jest tutaj .

W rzeczywistości bardzo trudno jest go GetHashCode()poprawnie wdrożyć, ponieważ oprócz reguł, o których już wspomniał Marc, kod skrótu nie powinien się zmieniać w trakcie życia obiektu. Dlatego pola używane do obliczania kodu skrótu muszą być niezmienne.

W końcu znalazłem rozwiązanie tego problemu, kiedy pracowałem z NHibernate. Moje podejście polega na obliczeniu kodu skrótu na podstawie identyfikatora obiektu. Identyfikator można ustawić tylko za pomocą konstruktora, więc jeśli chcesz zmienić identyfikator, co jest bardzo mało prawdopodobne, musisz utworzyć nowy obiekt, który ma nowy identyfikator, a zatem nowy kod skrótu. To podejście najlepiej działa z identyfikatorami GUID, ponieważ można dostarczyć konstruktora bez parametrów, który losowo generuje identyfikator.

Przesłaniając Equals, po prostu stwierdzasz, że jesteś tym, który wie lepiej, jak porównywać dwa wystąpienia danego typu, więc prawdopodobnie będziesz najlepszym kandydatem do zapewnienia najlepszego kodu skrótu.

Oto przykład, jak ReSharper pisze dla ciebie funkcję GetHashCode ():

public override int GetHashCode()
{
    unchecked
    {
        var result = 0;
        result = (result * 397) ^ m_someVar1;
        result = (result * 397) ^ m_someVar2;
        result = (result * 397) ^ m_someVar3;
        result = (result * 397) ^ m_someVar4;
        return result;
    }
}

Jak widać, po prostu próbuje odgadnąć dobry kod skrótu na podstawie wszystkich pól w klasie, ale skoro znasz domenę lub zakresy wartości swojego obiektu, nadal możesz podać lepszy.

Nie zapomnij sprawdzić parametru obj przed nullzastąpieniem Equals(). A także porównaj typ.

public override bool Equals(object obj)
{
    Foo fooItem = obj as Foo;

    if (fooItem == null)
    {
       return false;
    }

    return fooItem.FooId == this.FooId;
}

Powodem tego jest: Equalsmusi zwrócić false w porównaniu do null. Zobacz także http://msdn.microsoft.com/en-us/library/bsc2ak47.aspx

Co powiesz na:

public override int GetHashCode()
{
    return string.Format("{0}_{1}_{2}", prop1, prop2, prop3).GetHashCode();
}

Zakładając, że wydajność nie stanowi problemu :)

Mamy dwa problemy do rozwiązania.

1. Nie można podać sensownego, GetHashCode()jeśli można zmienić dowolne pole w obiekcie. Często też obiekt NIGDY nie będzie używany w kolekcji, od której zależy GetHashCode(). Tak więc koszt wdrożenia GetHashCode()często nie jest tego wart, lub nie jest to możliwe.

2. Jeśli ktoś umieści Twój obiekt w kolekcji, która wywołuje, GetHashCode()a Ty przesłoniłeś, Equals()nie GetHashCode()zachowując się również we właściwy sposób, osoba ta może spędzić dni na śledzeniu problemu.

Dlatego domyślnie tak.

public class Foo
{
    public int FooId { get; set; }
    public string FooName { get; set; }

    public override bool Equals(object obj)
    {
        Foo fooItem = obj as Foo;

        if (fooItem == null)
        {
           return false;
        }

        return fooItem.FooId == this.FooId;
    }

    public override int GetHashCode()
    {
        // Some comment to explain if there is a real problem with providing GetHashCode() 
        // or if I just don't see a need for it for the given class
        throw new Exception("Sorry I don't know what GetHashCode should do for this class");
    }
}

Wynika to z faktu, że struktura wymaga, aby dwa identyczne obiekty musiały mieć ten sam kod skrótu. Jeśli przesłonisz metodę równości, aby wykonać specjalne porównanie dwóch obiektów, a te dwa obiekty zostaną uznane przez metodę za identyczne, wówczas kod skrótu tych dwóch obiektów również musi być taki sam. (Słowniki i tabele skrótów opierają się na tej zasadzie).

Aby dodać powyższe odpowiedzi:

Jeśli nie zastąpisz opcji Równa się, domyślnym zachowaniem jest porównywanie odniesień do obiektów. To samo dotyczy hashcode - domyślna implementacja zwykle opiera się na adresie pamięci odniesienia. Ponieważ zastąpiłeś Equals, oznacza to, że poprawnym zachowaniem jest porównanie wszystkiego, co zaimplementowałeś w Equals, a nie referencji, więc powinieneś zrobić to samo dla kodu skrótu.

Klienci twojej klasy oczekują, że kod skrótu będzie miał logikę podobną do metody równości, na przykład metody linq, które używają IEqualityComparer najpierw porównają kody skrótu i ​​tylko jeśli są równe, porównają metodę Equals (), która może być droższa aby uruchomić, jeśli nie zaimplementujemy hashcode, równy obiekt prawdopodobnie będzie miał różne hashcode (ponieważ mają inny adres pamięci) i zostanie błędnie określony jako nierówny (Equals () nawet nie trafi).

Ponadto, z wyjątkiem problemu polegającego na tym, że możesz nie być w stanie znaleźć swojego obiektu, jeśli używałeś go w słowniku (ponieważ został on wstawiony przez jeden kod skrótu, a gdy go szukasz, domyślny kod skrótu prawdopodobnie będzie inny i znowu będzie równy () nawet nie zostanie wywołany, jak wyjaśnia Marc Gravell w swojej odpowiedzi, wprowadzasz również naruszenie słownika lub koncepcji skrótu, które nie powinny dopuszczać identycznych kluczy - już zadeklarowałeś, że te obiekty są zasadniczo takie same, gdy przesłonisz Equals, więc nie nie chcę obu z nich jako różnych kluczy w strukturze danych, które mają mieć unikalny klucz, ale ponieważ mają one inny kod skrótu, „ten sam” klucz zostanie wstawiony jako inny.

Kod skrótu jest używany w kolekcjach opartych na skrócie, takich jak Dictionary, Hashtable, HashSet itp. Celem tego kodu jest bardzo szybkie wstępne sortowanie określonego obiektu przez umieszczenie go w określonej grupie (segmencie). To wstępne sortowanie ogromnie pomaga w znalezieniu tego obiektu, gdy trzeba go odzyskać z kolekcji mieszania, ponieważ kod musi wyszukiwać obiekt w jednym wiadrze zamiast we wszystkich obiektach w nim zawartych. Im lepsza dystrybucja kodów skrótu (lepsza unikalność), tym szybsze pobieranie. W idealnej sytuacji, w której każdy obiekt ma unikalny kod skrótu, znalezienie go jest operacją O (1). W większości przypadków zbliża się do O (1).

To niekoniecznie ważne; zależy to od wielkości twoich kolekcji i wymagań dotyczących wydajności oraz od tego, czy Twoja klasa będzie używana w bibliotece, w której możesz nie znać wymagań dotyczących wydajności. Często wiem, że moje rozmiary kolekcji nie są bardzo duże, a mój czas jest cenniejszy niż kilka mikrosekund wydajności osiągniętej dzięki stworzeniu idealnego kodu skrótu; więc (aby pozbyć się irytującego ostrzeżenia kompilatora) po prostu używam:

   public override int GetHashCode()
   {
      return base.GetHashCode();
   }

(Oczywiście, mógłbym użyć #pragmy również do wyłączenia ostrzeżenia, ale wolę w ten sposób.)

Po pojawieniu się w położeniu, które nie potrzebują wydajność niż wszystkich zagadnień wymienionych przez innych tutaj zastosować, oczywiście. Najważniejsze - w przeciwnym razie przy pobieraniu elementów z zestawu skrótów lub słownika wystąpią błędne wyniki: kod skrótu nie może różnić się w zależności od czasu życia obiektu (a dokładniej w czasie, gdy potrzebny jest kod skrótu, na przykład podczas bycia klucz w słowniku): na przykład poniższe informacje są niepoprawne, ponieważ wartość jest publiczna i dlatego można ją zmienić zewnętrznie na klasę w czasie istnienia instancji, więc nie wolno jej używać jako podstawy kodu skrótu:

   class A
   {
      public int Value;

      public override int GetHashCode()
      {
         return Value.GetHashCode(); //WRONG! Value is not constant during the instance's life time
      }
   }    

Z drugiej strony, jeśli nie można zmienić wartości, można użyć:

   class A
   {
      public readonly int Value;

      public override int GetHashCode()
      {
         return Value.GetHashCode(); //OK  Value is read-only and can't be changed during the instance's life time
      }
   }

Zawsze powinieneś gwarantować, że jeśli dwa obiekty są równe, zgodnie z definicją Equals (), powinny zwrócić ten sam kod skrótu. Jak twierdzą niektóre inne komentarze, teoretycznie nie jest to obowiązkowe, jeśli obiekt nigdy nie będzie używany w kontenerze opartym na haszowaniu, takim jak HashSet lub Dictionary. Radziłbym ci jednak zawsze przestrzegać tej zasady. Powodem jest po prostu to, że zbyt łatwo jest komuś zmienić kolekcję z jednego typu na inny z dobrym zamiarem faktycznej poprawy wydajności lub po prostu lepszego przekazania semantyki kodu.

Załóżmy na przykład, że przechowujemy niektóre obiekty na liście. Jakiś czas później ktoś faktycznie zdaje sobie sprawę, że HashSet jest znacznie lepszą alternatywą, na przykład ze względu na lepszą charakterystykę wyszukiwania. To wtedy możemy wpaść w kłopoty. Lista wewnętrznie użyje domyślnego modułu porównującego równość dla typu, co w twoim przypadku oznacza Equals, podczas gdy HashSet korzysta z GetHashCode (). Jeśli oba zachowują się inaczej, twój program również. I pamiętaj, że takie problemy nie są najłatwiejsze do rozwiązania.

Podsumowałem to zachowanie przy pomocy innych pułapek GetHashCode () w poście na blogu, gdzie można znaleźć dalsze przykłady i wyjaśnienia.

Jako .NET 4.7preferowaną metodę zastępowania GetHashCode()pokazano poniżej. Jeśli celujesz w starsze wersje .NET, dołącz pakiet nuget System.ValueTuple .

// C# 7.0+
public override int GetHashCode() => (FooId, FooName).GetHashCode();

Pod względem wydajności ta metoda przewyższy większość implementacji złożonego kodu mieszającego. ValueTuple jeststruct tak, że nie będzie żadnych śmieci, a algorytm bazowy jest tak szybko, jak to tylko możliwe.

Rozumiem, że pierwotna funkcja GetHashCode () zwraca adres pamięci obiektu, więc konieczne jest zastąpienie go, jeśli chcesz porównać dwa różne obiekty.

ZMIENIONO: To było niepoprawne, oryginalna metoda GetHashCode () nie może zapewnić równości 2 wartości. Jednak równe obiekty zwracają ten sam kod skrótu.

Poniżej użycie refleksji wydaje mi się lepszą opcją biorąc pod uwagę właściwości publiczne, ponieważ dzięki temu nie musisz się martwić o dodawanie / usuwanie właściwości (choć nie tak powszechny scenariusz). Okazało się, że również działa lepiej (w porównaniu do czasu przy użyciu stopera Diagonistics).

    public int getHashCode()
    {
        PropertyInfo[] theProperties = this.GetType().GetProperties();
        int hash = 31;
        foreach (PropertyInfo info in theProperties)
        {
            if (info != null)
            {
                var value = info.GetValue(this,null);
                if(value != null)
                unchecked
                {
                    hash = 29 * hash ^ value.GetHashCode();
                }
            }
        }
        return hash;  
    }