Что вернуть при переопределении Object.GetHashCode() в классах без неизменяемых полей?

Вернитесь к основам. Вы читали мою статью; прочитайте это снова. Два железных правила, которые имеют отношение к вашей ситуации:

• если x равно y, то хеш-код x должен быть равен хэш-коду y. Эквивалентно: если хэш-код x не равен хэш-коду y, тогда x и y должны быть неравны.
• хэш-код x должен оставаться стабильным, пока x находится в хеш-таблице.

Это требования для правильности. Если вы не можете гарантировать эти две простые вещи, ваша программа не будет правильной.

Вы предлагаете два решения.

Ваше первое решение заключается в том, что вы всегда возвращаете константу. Это соответствует требованиям обоих правил, но тогда вы сведетесь к линейному поиску в своей хеш-таблице. Вы также можете использовать список.

Другое решение, которое вы предлагаете, состоит в том, чтобы каким-то образом создать хэш-код для каждого объекта и сохранить его в объекте. Это совершенно законно, при условии, что одинаковые элементы имеют одинаковые хеш-коды. Если вы сделаете это, вы будете ограничены таким образом, что x равно y должно быть ложным, если хеш-коды различаются. Кажется, что это делает равенство значений практически невозможным. Поскольку вы не стали бы переопределять Equals в первую очередь, если бы хотели равенства ссылок, это кажется действительно плохой идеей, но это законно при условии, что equals непротиворечиво.

Я предлагаю третье решение, а именно: никогда не помещайте свой объект в хеш-таблицу, потому что хеш-таблица — это, прежде всего, неправильная структура данных. Смысл хеш-таблицы в том, чтобы быстро ответить на вопрос «является ли данное значение данным набором неизменяемых значений?» и у вас нет набора неизменяемых значений, поэтому не используйте хеш-таблицу. Используйте правильный инструмент для работы. Используйте список и живите с болью линейного поиска.

Четвертое решение: хешируйте изменяемые поля, используемые для равенства, удаляйте объект из всех хеш-таблиц, в которых он находится, непосредственно перед каждым его изменением, а затем возвращайте его обратно. Это соответствует обоим требованиям: хэш-код соответствует равенству, хэши объектов в хеш-таблицах стабильны, и вы по-прежнему получаете быстрый поиск.

Я бы либо создал дополнительное поле readonly, либо выкинул бы NotSupportedException. На мой взгляд, другой вариант бессмысленен. Давайте посмотрим, почему.

Отдельные (фиксированные) хэш-коды

Предоставление различных хэш-кодов легко, например:

class Sample
{
    private static int counter;
    private readonly int hashCode;

    public Sample() { this.hashCode = counter++; }

    public override int GetHashCode()
    {
        return this.hashCode;
    }

    public override bool Equals(object other)
    {
        return object.ReferenceEquals(this, other);
    }
}

Технически вы должны следить за созданием слишком большого количества объектов и переполнением counter здесь, но на практике я думаю, что это не будет проблемой ни для кого.

Проблема с этим подходом заключается в том, что экземпляры никогда не будут сравниваться как равные. Однако это совершенно нормально, если вы хотите использовать только экземпляры Sample в качестве индексов в коллекции какого-либо другого типа.

Постоянные хэш-коды

Если есть какой-либо сценарий, в котором отдельные экземпляры должны сравниваться как равные, то на первый взгляд у вас нет другого выбора, кроме как вернуть константу. Но где это оставляет вас?

Поиск экземпляра внутри контейнера всегда сводится к эквиваленту линейного поиска. Таким образом, возвращая константу, вы позволяете пользователю создать контейнер с ключом для вашего класса, но этот контейнер будет демонстрировать характеристики производительности LinkedList<T>. Это может быть очевидно для тех, кто знаком с вашим классом, но лично я считаю, что это позволяет людям стрелять себе в ногу. Если вы заранее знаете, что Dictionary не будет вести себя так, как можно было бы ожидать, то зачем позволять пользователю создавать его? На мой взгляд, лучше выкинуть NotSupportedException.

Но бросать - это то, чего делать нельзя!

Некоторые люди не согласятся с вышесказанным, и когда эти люди умнее тебя, то следует обратить внимание. Прежде всего, в предупреждении об анализе кода говорится, что GetHashCode не должен вызывать ошибки. Это то, о чем следует подумать, но давайте не будем догматиками. Иногда приходится нарушать правила по какой-то причине.

Однако это еще не все. В своем сообщении в блоге тему, Эрик Липперт говорит, что если бросить изнутри GetHashCode, то

ваш объект не может быть результатом многих запросов LINQ-to-objects, которые используют внутренние хеш-таблицы из соображений производительности.

Потеря LINQ — это, конечно, облом, но, к счастью, на этом дорога не заканчивается. Многие (все?) методы LINQ, использующие хеш-таблицы, имеют перегрузки, которые принимают IEqualityComparer<T> для использования при хешировании. Таким образом, вы можете использовать LINQ, но это будет менее удобно.

В конце концов, вам придется взвешивать варианты самостоятельно. Мое мнение таково, что лучше работать со стратегией белого списка (предоставлять IEqualityComparer<T> всякий раз, когда это необходимо), если это технически возможно, потому что это делает код явным: если кто-то пытается использовать класс наивно, он получает исключение, которое полезно сообщает ему, что происходит, и компаратор равенства виден в коде, где бы он ни использовался, что сразу же делает неординарное поведение класса очевидным.

Там, где я хочу переопределить Equals, но нет толкового неизменяемого «ключа» для объекта (и по какой-то причине нет смысла делать неизменяемым весь объект), на мой взгляд, есть только один «правильный» выбор:

• Реализуйте GetHashCode для хеширования тех же полей, которые использует Equals. (Это могут быть все поля.)
• Задокументируйте, что эти поля нельзя изменять в словаре.
• Поверьте, что пользователи либо не помещают эти объекты в словари, либо подчиняются второму правилу.

(Возвращение постоянного значения ставит под угрозу производительность словаря. Генерация исключения запрещает слишком много полезных случаев, когда объекты кэшируются, но не изменяются. Любая другая реализация для GetHashCode была бы неправильной.)

Там, где это все равно создает проблемы пользователю, это, вероятно, его вина. (В частности: использование словаря, где они не должны, или использование типа модели в контексте, где они должны использовать тип модели представления, который вместо этого использует ссылочное равенство.)

Или, возможно, мне вообще не следует переопределять Equals.

Если классы действительно не содержат ничего постоянного, по которому можно вычислить хеш-значение, я бы использовал что-то более простое, чем GUID. Просто используйте случайное число, сохраненное в классе (или в классе-оболочке).

Простой подход состоит в том, чтобы сохранить хэш-код в частном члене и сгенерировать его при первом использовании. Если ваша сущность не меняется часто, и вы не собираетесь использовать два разных объекта Equal (где ваш метод Equals возвращает true) в качестве ключей в вашем словаре, тогда это должно быть хорошо:

private int? _hashCode;

public override int GetHashCode() {
   if (!_hashCode.HasValue)
      _hashCode = Property1.GetHashCode() ^ Property2.GetHashCode() etc... based on whatever you use in your equals method
   return _hashCode.Value;
}

Однако, если у вас есть, скажем, объект a и объект b, где a.Equals(b) == true, и вы сохраняете запись в своем словаре, используя a в качестве ключа (dictionary[a] = value).
Если а не изменится, то словарь[b] вернет значение, однако, если изменить а после сохранения записи в словаре, то словарь[b], скорее всего, не удастся. Единственный обходной путь — перефразировать словарь при изменении любого из ключей.