Чому важливо переосмислити GetHashCode, коли метод Equals буде замінено?

Дано наступний клас

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

Я змінив Equalsметод, тому що Fooпредставляє рядок для Fooтаблиці s. Який спосіб є кращим для переосмислення GetHashCode?

Чому важливо переосмислити GetHashCode?

Так, важливо, якщо ваш елемент буде використовуватися як ключ у словнику, або HashSet<T>тощо - оскільки це використовується (за відсутності спеціального користування IEqualityComparer<T>) для групування елементів у відрі. Якщо хеш-код для двох елементів не збігається, вони ніколи не можуть вважатися рівними ( Рівні просто ніколи не будуть називатися).

Метод GetHashCode () повинен відображати Equalsлогіку; правила такі:

• якщо дві речі рівні ( Equals(...) == true), вони повинні повернути однакове значення дляGetHashCode()
• якщо GetHashCode()рівні рівні, не потрібно, щоб вони були однаковими; це зіткнення, і Equalsбуде покликано перевірити, чи справжня це рівність чи ні.

У цьому випадку, схоже, що " return FooId;" є відповідною GetHashCode()реалізацією. Якщо ви тестуєте кілька властивостей, звичайно їх комбінувати за допомогою коду, як показано нижче, щоб зменшити діагональні зіткнення (тобто так, що new Foo(3,5)має інший хеш-код 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;
}

Ох - для зручності ви також можете розглянути питання про надання ==та !=операторів при переопределенні Equalsта GetHashCode.

Демонстрація того, що відбувається, коли ви помилитесь, є тут .

Насправді це дуже важко GetHashCode()правильно реалізувати, оскільки, крім правил, про які вже говорив Марк, хеш-код не повинен змінюватися протягом життя об’єкта. Тому поля, які використовуються для обчислення хеш-коду, повинні бути незмінними.

Нарешті я знайшов рішення цієї проблеми, коли працював з NHibernate. Мій підхід полягає в обчисленні хеш-коду з ідентифікатора об'єкта. Ідентифікатор можна встановити лише конструктором, тому якщо ви хочете змінити ідентифікатор, що малоймовірно, вам доведеться створити новий об'єкт, який має новий ідентифікатор, а отже, і новий хеш-код. Цей підхід найкраще працює з GUID, оскільки ви можете надати конструктор без параметрів, який випадково генерує ідентифікатор.

Заперечуючи рівне, ви в основному заявляєте, що ви є тим, хто краще знає, як порівнювати два екземпляри даного типу, тож ви, ймовірно, будете найкращим кандидатом для надання найкращого хеш-коду.

Це приклад того, як ReSharper пише функцію 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;
    }
}

Як ви бачите, він просто намагається відгадати хороший хеш-код на основі всіх полів у класі, але, оскільки ви знаєте домен або діапазон значень вашого об'єкта, ви все ще можете надати кращий.

Не забудьте перевірити параметр obj nullпри переопределенні Equals(). А також порівняйте тип.

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

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

    return fooItem.FooId == this.FooId;
}

Причина цього: Equalsповинна повертати помилкове порівняння з null. Дивіться також http://msdn.microsoft.com/en-us/library/bsc2ak47.aspx

Як щодо:

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

Якщо припустити, що це не проблема :)

У нас є дві проблеми, з якими можна впоратися.

1. Ви не можете надати розумного, GetHashCode()якщо будь-яке поле в об'єкті може бути змінено. Також часто об'єкт НІКОЛИ не буде використаний у колекції, від якої залежить GetHashCode(). Тож витрати на реалізацію GetHashCode()часто не варті, або це неможливо.

2. Якщо хтось поміщає ваш об’єкт у колекцію, яка дзвонить, GetHashCode()і ви переосмислили, Equals()не змушуючи GetHashCode()себе вести себе правильно, ця людина може витратити дні на відстеження проблеми.

Тому я за замовчуванням роблю.

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

Це тому, що рамки вимагають, щоб два об'єкти, які однакові, повинні мати однаковий хеш-код. Якщо ви перекриєте метод рівних, щоб зробити спеціальне порівняння двох об'єктів, і два об'єкти методом вважаються однаковими, то і хеш-код двох об'єктів також повинен бути однаковим. (Словники та хештейли покладаються на цей принцип).

Просто додати відповіді вище:

Якщо ви не переосмислюєте рівність, то типовою поведінкою є порівняння посилань на об'єкти. Це ж стосується і хеш-коду - імплікація за замовчуванням, як правило, базується на адресі пам'яті посилання. Оскільки ви переопрацювали рівний, це означає, що правильна поведінка полягає в порівнянні того, що ви реалізували на рівних, а не посиланнях, тому ви повинні зробити те ж саме для хеш-коду.

Клієнти вашого класу очікують, що хеш-код має подібну логіку до методу рівних, наприклад методики linq, які використовують IEqualityComparer, спочатку порівнюють хеш-коди, і лише якщо вони рівні, вони порівняють метод Equals (), який може бути дорожчим запустити, якщо ми не реалізували хеш-код, рівний об’єкт, ймовірно, матиме різні хеш-коди (оскільки вони мають різну адресу пам'яті) і буде визначений помилково, як не рівний (Equals () навіть не потрапить).

Крім того, за винятком проблеми, що ви не зможете знайти свій об'єкт, якби ви використовували його у словнику (тому що він був вставлений одним хеш-кодом, і коли ви шукаєте його, хеш-код за замовчуванням, ймовірно, буде іншим, і знову дорівнює () навіть не зателефонуйте, як пояснює Марк Гравелл у своїй відповіді, ви також вводите порушення словника або поняття хештету, яке не повинно допускати однакових ключів - ви вже заявили, що ці об'єкти є по суті однаковими, коли ви переобираєте рівність, так що ви не Я не хочу, щоб обидва вони були різними ключами структури даних, які, мабуть, мають унікальний ключ, але оскільки у них інший хеш-код, "той самий" ключ буде вставлений як інший.

Хеш-код використовується для колекцій на основі хешів, таких як словник, Hashtable, HashSet тощо. Метою цього коду є дуже швидке попереднє впорядкування конкретного об'єкта шляхом його розміщення в певну групу (відро). Це попереднє сортування надзвичайно допомагає знайти цей об’єкт, коли вам потрібно повернути його з колекції хешів, оскільки код повинен шукати ваш об’єкт лише в одному відрі, а не в усіх об'єктах, які він містить. Чим кращий розподіл хеш-кодів (краща унікальність), тим швидше пошук. В ідеальній ситуації, коли кожен об’єкт має унікальний хеш-код, виявлення це операція O (1). У більшості випадків воно наближається до O (1).

Це не обов'язково важливо; це залежить від розміру ваших колекцій та ваших вимог до продуктивності та від того, чи буде ваш клас використовуватися в бібліотеці, де ви, можливо, не знаєте вимог до продуктивності. Я часто знаю, що розміри моїх колекцій не дуже великі, і мій час цінніший, ніж кілька мікросекунд продуктивності, отриманих створенням ідеального хеш-коду; тож (щоб позбутися набридливого попередження компілятором) я просто використовую:

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

(Звичайно, я можу використовувати #pragma, щоб також відключити попередження, але я вважаю за краще цей спосіб.)

Коли ви перебуваєте в позиції , що ви дійсно потребуєте продуктивності , ніж всі питання , згадані іншими тут застосовні, звичайно. Найголовніше - інакше ви отримаєте помилкові результати при отриманні елементів із набору хеш-словника чи словника: хеш-код не повинен змінюватися залежно від часу життя об’єкта (точніше, протягом часу, коли потрібен хеш-код, наприклад, під час перебування ключ у словнику): наприклад, таке неправильне, оскільки Value є загальнодоступним, і тому його можна змінити зовнішньо до класу впродовж життя екземпляра, тому ви не повинні використовувати його як основу для хеш-коду:

   class A
   {
      public int Value;

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

З іншого боку, якщо значення не можна змінити, це нормально:

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

Ви завжди повинні гарантувати, що якщо два об'єкти рівні, як визначено рівним (), вони повинні повертати один і той же хеш-код. Як зазначають деякі інші коментарі, теоретично це не є обов'язковим, якщо об'єкт ніколи не буде використовуватися в контейнері на основі хешу, як HashSet або Dictionary. Я б радив вам завжди дотримуватися цього правила. Причина полягає лише в тому, що комусь занадто просто змінити колекцію від одного типу до іншого з хорошим наміром фактично покращити продуктивність або просто передати семантику коду кращим чином.

Наприклад, припустимо, що ми зберігаємо деякі об’єкти у списку. Десь пізніше хтось фактично усвідомлює, що HashSet є набагато кращою альтернативою, наприклад, завдяки кращим пошуковим характеристикам. Це коли ми можемо потрапити в біду. Список буде внутрішньо використовувати порівняльник рівності за замовчуванням для типу, який означає рівний у вашому випадку, тоді як HashSet використовує GetHashCode (). Якщо вони поводяться по-різному, так і ваша програма. І майте на увазі, що подібні питання не найлегше вирішити.

Я узагальнив цю поведінку з деякими іншими підводними кодами GetHashCode () у публікації блогу, де ви можете знайти подальші приклади та пояснення.

Щодо .NET 4.7кращого способу переосмислення GetHashCode()показано нижче. Якщо ви орієнтовані на більш старі версії .NET, включіть нульовий пакет System.ValueTuple .

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

За рівнем продуктивності цей метод перевершить більшість складених хеш-кодів. ValueTuple є structтак що не буде ніякого сміття, і основний алгоритм так швидко , як він отримує.

Наскільки я розумію, що оригінальний GetHashCode () повертає адресу пам'яті об'єкта, тому важливо переосмислити його, якщо ви хочете порівняти два різних об'єкти.

ВЕДЕНО: Це було неправильно, оригінальний метод GetHashCode () не може забезпечити рівність двох значень. Хоча об'єкти, які є рівними, повертають один і той же хеш-код.

Нижче використання рефлексії здається мені кращим варіантом, враховуючи загальнодоступні властивості, оскільки з цим вам не доведеться турбуватися про додавання / видалення властивостей (хоча це не такий поширений сценарій). Це я виявив і більш ефективним. (Порівняння часу за допомогою секундоміра 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;  
    }