Perché è importante sovrascrivere GetHashCode quando il metodo Equals viene sostituito?

Data la seguente classe

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();
    }
}

Ho ignorato il Equalsmetodo perché Foorappresentano una riga per la Footabella s. Qual è il metodo preferito per sovrascrivere il GetHashCode?

Perché è importante eseguire l'override GetHashCode?

Sì, è importante se il tuo articolo verrà utilizzato come chiave in un dizionario o HashSet<T>, ecc., Poiché viene utilizzato (in assenza di un'abitudine IEqualityComparer<T>) per raggruppare gli elementi in bucket. Se l'hash-code per due elementi non corrisponde, possono mai essere considerati uguali ( Equals saranno semplicemente mai essere chiamati).

Il metodo GetHashCode () dovrebbe riflettere la Equalslogica; le regole sono:

• se due cose sono uguali ( Equals(...) == true), allora devono restituire lo stesso valore perGetHashCode()
• se GetHashCode()è uguale, è non necessaria per loro di essere la stessa; questa è una collisione e Equalsverrà chiamata per vedere se è una vera uguaglianza o no.

In questo caso, sembra che " return FooId;" sia GetHashCode()un'implementazione adatta . Se stai testando più proprietà, è comune combinarle usando il codice come sotto, per ridurre le collisioni diagonali (cioè in modo che new Foo(3,5)abbia un codice hash diverso da 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;
}

Oh - per comodità, potresti anche considerare di fornire ==e !=operatori quando esegui l'override Equalse GetHashCode.

Una dimostrazione di ciò che accade quando si sbaglia questo è qui .

In realtà è molto difficile da implementare GetHashCode()correttamente perché, oltre alle regole già citate da Marc, il codice hash non dovrebbe cambiare durante la vita di un oggetto. Pertanto, i campi utilizzati per calcolare il codice hash devono essere immutabili.

Alla fine ho trovato una soluzione a questo problema mentre lavoravo con NHibernate. Il mio approccio è calcolare il codice hash dall'ID dell'oggetto. L'ID può essere impostato solo tramite il costruttore, quindi se si desidera modificare l'ID, il che è molto improbabile, è necessario creare un nuovo oggetto con un nuovo ID e quindi un nuovo codice hash. Questo approccio funziona meglio con i GUID perché è possibile fornire un costruttore senza parametri che genera in modo casuale un ID.

Sovrascrivendo Equals stai sostanzialmente affermando di essere quello che sa meglio come confrontare due istanze di un determinato tipo, quindi probabilmente sarai il miglior candidato per fornire il miglior codice hash.

Questo è un esempio di come ReSharper scrive una funzione GetHashCode () per te:

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;
    }
}

Come puoi vedere, cerca solo di indovinare un buon codice hash basato su tutti i campi della classe, ma poiché conosci il dominio del tuo oggetto o gli intervalli di valori, puoi comunque fornirne uno migliore.

Si prega di non dimenticare di controllare il parametro obj contro nullquando si esegue l'override Equals(). E confronta anche il tipo.

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

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

    return fooItem.FooId == this.FooId;
}

Il motivo di ciò è: Equalsdeve restituire false in confronto a null. Vedi anche http://msdn.microsoft.com/en-us/library/bsc2ak47.aspx

Che ne dite di:

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

Supponendo che le prestazioni non siano un problema :)

Abbiamo due problemi da affrontare.

1. Non è possibile fornire un valore ragionevole GetHashCode()se è possibile modificare qualsiasi campo nell'oggetto. Inoltre spesso un oggetto non verrà MAI utilizzato in una raccolta che dipende da GetHashCode(). Quindi il costo di implementazione GetHashCode()spesso non ne vale la pena, o non è possibile.

2. Se qualcuno inserisce il tuo oggetto in una raccolta che chiama GetHashCode()e hai eseguito l'override Equals()senza anche GetHashCode()comportarti in modo corretto, quella persona potrebbe passare giorni a rintracciare il problema.

Pertanto, per impostazione predefinita, lo faccio.

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");
    }
}

È perché il framework richiede che due oggetti uguali debbano avere lo stesso hashcode. Se si sovrascrive il metodo equals per eseguire un confronto speciale di due oggetti e i due oggetti vengono considerati uguali dal metodo, anche il codice hash dei due oggetti deve essere lo stesso. (I dizionari e gli hashtable si basano su questo principio).

Solo per aggiungere le risposte sopra:

Se non si sostituisce Equals, il comportamento predefinito è che i riferimenti degli oggetti vengono confrontati. Lo stesso vale per l'hashcode: l'implementazione predefinita si basa in genere su un indirizzo di memoria del riferimento. Dato che hai sovrascritto Equals significa che il comportamento corretto è quello di confrontare qualsiasi cosa tu abbia implementato su Equals e non i riferimenti, quindi dovresti fare lo stesso per l'hashcode.

I clienti della tua classe si aspetteranno che l'hashcode abbia una logica simile al metodo equals, ad esempio i metodi linq che usano un IEqualityComparer prima confrontano gli hashcodes e solo se sono uguali confronteranno il metodo Equals () che potrebbe essere più costoso per funzionare, se non abbiamo implementato l'hashcode, l'oggetto uguale avrà probabilmente hashcode diversi (perché hanno un indirizzo di memoria diverso) e sarà determinato erroneamente perché non uguale (Equals () non colpirà nemmeno).

Inoltre, tranne il problema che potresti non essere in grado di trovare l'oggetto se lo hai utilizzato in un dizionario (perché è stato inserito da un hashcode e quando lo cerchi, l'hashcode predefinito sarà probabilmente diverso e, di nuovo, Equals () non verrà nemmeno chiamato, come spiega Marc Gravell nella sua risposta, si introduce anche una violazione del dizionario o del concetto di hashset che non dovrebbe consentire chiavi identiche - hai già dichiarato che quegli oggetti sono essenzialmente gli stessi quando si supera gli Equals, quindi si vorranno entrambi come chiavi diverse su una struttura di dati che supponga di avere una chiave univoca, ma poiché hanno un codice hash diverso la "stessa" chiave verrà inserita come diversa.

Il codice hash viene utilizzato per raccolte basate su hash come Dictionary, Hashtable, HashSet ecc. Lo scopo di questo codice è preordinare molto rapidamente un oggetto specifico inserendolo in un gruppo specifico (bucket). Questo pre-ordinamento aiuta enormemente a trovare questo oggetto quando è necessario recuperarlo dalla raccolta hash perché il codice deve cercare l'oggetto in un solo bucket anziché in tutti gli oggetti che contiene. La migliore distribuzione dei codici hash (migliore unicità) il recupero più veloce. Nella situazione ideale in cui ogni oggetto ha un codice hash univoco, trovarlo è un'operazione O (1). Nella maggior parte dei casi si avvicina a O (1).

Non è necessariamente importante; dipende dalle dimensioni delle raccolte e dai requisiti di rendimento e se la classe verrà utilizzata in una libreria in cui potresti non conoscere i requisiti di rendimento. So spesso che le dimensioni della mia collezione non sono molto grandi e il mio tempo è più prezioso di alcuni microsecondi di prestazioni ottenute creando un codice hash perfetto; quindi (per sbarazzarmi del fastidioso avvertimento del compilatore) uso semplicemente:

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

(Ovviamente potrei usare un #pragma anche per disattivare l'avviso ma preferisco così.)

Quando si è nella posizione che non ha bisogno delle prestazioni di tutti i problemi citati da altri qui si applicano, naturalmente. La cosa più importante - altrimenti otterrai risultati errati quando recuperi elementi da un set di hash o da un dizionario: il codice hash non deve variare con la durata di vita di un oggetto (più precisamente, durante il tempo in cui è necessario il codice hash, ad esempio una chiave in un dizionario): ad esempio, quanto segue è errato poiché Value è pubblico e quindi può essere modificato esternamente alla classe durante il periodo di vita dell'istanza, quindi non è necessario utilizzarlo come base per il codice hash:

   class A
   {
      public int Value;

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

D'altra parte, se il valore non può essere modificato, va bene usare:

   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
      }
   }

Dovresti sempre garantire che se due oggetti sono uguali, come definito da Equals (), dovrebbero restituire lo stesso codice hash. Come alcuni altri commenti affermano, in teoria questo non è obbligatorio se l'oggetto non verrà mai utilizzato in un contenitore basato su hash come HashSet o Dictionary. Ti consiglio comunque di seguire sempre questa regola. Il motivo è semplicemente perché è troppo facile per qualcuno cambiare una raccolta da un tipo a un altro con la buona intenzione di migliorare effettivamente le prestazioni o semplicemente trasmettere la semantica del codice in un modo migliore.

Ad esempio, supponiamo di conservare alcuni oggetti in un elenco. Qualche tempo dopo qualcuno si rende conto che un HashSet è un'alternativa molto migliore a causa, ad esempio, delle migliori caratteristiche di ricerca. Questo è quando possiamo metterci nei guai. Elenco userebbe internamente il comparatore di uguaglianza predefinito per il tipo che significa Equals nel tuo caso mentre HashSet utilizza GetHashCode (). Se i due si comportano diversamente, lo sarà anche il tuo programma. E tieni presente che tali problemi non sono i più facili da risolvere.

Ho riassunto questo comportamento con alcune altre insidie ​​di GetHashCode () in a post sul blog in cui è possibile trovare ulteriori esempi e spiegazioni.

Di seguito viene mostrato .NET 4.7il metodo preferito di sostituzione GetHashCode(). Se si sceglie come target versioni precedenti di .NET, includere il pacchetto nuget System.ValueTuple .

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

In termini di prestazioni, questo metodo supererà la maggior parte delle implementazioni di codice hash composito . Il ValueTuple è structquindi non ci sarà alcun rifiuti, e l'algoritmo sottostante è veloce come ottiene.

Comprendo che GetHashCode originale () restituisce l'indirizzo di memoria dell'oggetto, quindi è essenziale sovrascriverlo se si desidera confrontare due diversi oggetti.

EDITED: errato, il metodo GetHashCode () originale non può assicurare l'uguaglianza di 2 valori. Sebbene oggetti uguali restituiscano lo stesso codice hash.

Di seguito usare la riflessione mi sembra un'opzione migliore considerando le proprietà pubbliche in quanto con questo non devi preoccuparti dell'aggiunta / rimozione di proprietà (anche se non è uno scenario così comune). Anche questo mi ha permesso di ottenere prestazioni migliori (tempo confrontato con il cronometro 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;  
    }