Jak mam wdrożyć Object.GetHashCode() dla złożonej równości?

Question

Zasadniczo mam następujące pory:

class Foo { 
    public override bool Equals(object obj) 
    { 
     Foo d = obj as Foo ; 
     if (d == null) 
      return false; 

     return this.Equals(d); 
    } 

    #region IEquatable<Foo> Members 

    public bool Equals(Foo other) 
    { 
     if (this.Guid != String.Empty && this.Guid == other.Guid) 
      return true; 
     else if (this.Guid != String.Empty || other.Guid != String.Empty) 
      return false; 

     if (this.Title == other.Title && 
      this.PublishDate == other.PublishDate && 
      this.Description == other.Description) 
      return true; 

     return false; 
    } 
} 

Tak, problem jest taki: mam non-wymagane pole Guid, który jest unikatowy identyfikator. Jeśli nie jest to ustawione, muszę spróbować określić równość w oparciu o mniej dokładne metryki jako próbę określenia, czy dwa obiekty są równe. Działa to dobrze, ale sprawia, że ​​GetHashCode() jest brudny ... Jak powinienem to zrobić? Naiwna implementacja byłaby podobna do:

public override int GetHashCode() { 
    if (this.Guid != String.Empty) 
     return this.Guid.GetHashCode(); 

    int hash = 37; 
    hash = hash * 23 + this.Title.GetHashCode(); 
    hash = hash * 23 + this.PublishDate.GetHashCode(); 
    hash = hash * 23 + this.Description.GetHashCode(); 
    return hash; 
} 

Ale jakie są szanse na zderzenie dwóch typów hasha? Oczywiście, nie oczekiwałbym, że będzie to 1 in 2 ** 32. Czy to zły pomysł, a jeśli tak, to w jaki sposób powinienem to robić?

Answer 1

Nie sądzę, że jest jakiś problem z podejściem, które wybrałeś. Niepokojące "zbyt dużo" o kolizjach hash jest prawie zawsze oznaką nadmiernego myślenia o problemie; tak długo, jak mieszanie jest bardzo prawdopodobne, powinno być w porządku.

Ostatecznie możesz nawet rozważyć pominięcie wartości Description ze swojego skrótu, jeśli uzasadnione jest oczekiwanie, że w większości przypadków obiekty można odróżnić na podstawie tytułu i daty publikacji (książki?).

Można nawet rozważyć lekceważenie identyfikatora GUID w funkcji haszowania i używać go tylko w implementacji Equals, aby ujednoznacznić mało prawdopodobny (?) Przypadek konfliktów hash.

Answer 2

Bardzo łatwy hash code method for custom classes jest bitowe XOR każdego z kodów hash pól razem. To może być tak proste, jak to:

int hash = 0; 
hash ^= this.Title.GetHashCode(); 
hash ^= this.PublishDate.GetHashCode(); 
hash ^= this.Description.GetHashCode(); 
return hash; 

Z link above:

XOR ma następujące właściwości ładne:

• to nie zależy od kolejności obliczeń.
• Nie "marnuje" bitów. Jeśli zmienisz nawet jeden bit w jednym ze składników, ostateczna wartość zmieni się.
• Jest szybki, pojedynczy cykl na nawet najbardziej prymitywnym komputerze.
• Umożliwia zachowanie jednolitego rozkładu. Jeśli oba połączone elementy są równomiernie rozmieszczone, tak będzie połączenie. Innymi słowy, nie ma tendencji do zwijania zakresu trawienia do węższego pasma.

XOR nie działa dobrze, jeśli można oczekiwać, aby mieć zduplikowane wartości w polach jak zduplikowane wartości będą znoszą się nawzajem, kiedy XORed. Ponieważ mieszamy razem trzy niepowiązane pola, które nie powinny w tym przypadku stanowić problemu.