Переопределение GetHashCode для изменяемых объектов?

Как это работает, если поля, на которых он основан, являются изменяемыми?

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

Также что, если я хочу, чтобы поиск в словаре и т. Д. Был основан на равенстве ссылок, а не на моих переопределенных Equals?

Пока вы реализуете интерфейс типа IEquatable<T>, это не должно быть проблемой. Большинство реализаций словарей выбирают компаратор равенства таким образом, чтобы использовать IEquatable<T> вместо Object.ReferenceEquals. Даже без IEquatable<T> большинство из них по умолчанию будет вызывать Object.Equals (), который затем войдет в вашу реализацию.

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

Если вы ожидаете, что ваши объекты будут вести себя с равенством значений, вам следует переопределить == и! =, Чтобы обеспечить равенство значений для всех сравнений. Пользователи по-прежнему могут использовать Object.ReferenceEquals, если им действительно нужно ссылочное равенство.

Раньше я предполагал, что фреймворк всегда использует ==, а не Equals для сравнения.

То, что использует BCL, со временем немного изменилось. Теперь в большинстве случаев, в которых используется равенство, будет использоваться IEqualityComparer<T> экземпляр для проверки равенства. В случаях, когда один не указан, они будут использовать EqualityComparer<T>.Default, чтобы найти его. В худшем случае по умолчанию будет вызывать Object.Equals

Если у вас есть изменяемый объект, нет особого смысла переопределять метод GetHashCode, поскольку вы действительно не можете его использовать. Например, он используется коллекциями Dictionary и HashSet для помещения каждого элемента в корзину. Если вы измените объект, когда он используется в качестве ключа в коллекции, хэш-код больше не будет соответствовать сегменту, в котором находится объект, поэтому коллекция не будет работать должным образом, и вы, возможно, никогда больше не найдете объект.

Если вы хотите, чтобы поиск не использовал GetHashCode или Equals метод класса, вы всегда можете предоставить свою собственную реализацию IEqualityComparer для использования вместо этого при создании Dictionary.

Метод Equals предназначен для обеспечения равенства значений, поэтому правильно его реализовать.

Вау, на самом деле это несколько вопросов в одном :-). Так по порядку:

упоминалось, что значение GetHashCode никогда не должно изменяться за время существования объекта. Как это работает, если поля, на которых он основан, являются изменяемыми?

Этот общий совет предназначен для случая, когда вы хотите использовать свой объект в качестве ключа в HashTable / словаре и т. Д. HashTables обычно требует, чтобы хеш не изменялся, потому что они используют его, чтобы решить, как хранить и извлекать ключ. Если хеш изменится, HashTable, вероятно, больше не найдет ваш объект.

Чтобы процитировать документацию интерфейса Java Map:

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

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

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

Также что, если я хочу, чтобы поиск в словаре и т. Д. Был основан на равенстве ссылок, а не на моих переопределенных Equals?

Что ж, найдите словарную реализацию, которая так работает. Но словари стандартной библиотеки используют хэш-код & Equals, и изменить это невозможно.

Я в первую очередь переопределяю Equals для простоты модульного тестирования моего кода сериализации, который, как я предполагаю, сериализация и десериализация (в моем случае в XML) убивает ссылочное равенство, поэтому я хочу убедиться, что, по крайней мере, он верен по равенству значений. Является ли в данном случае плохой практикой переопределение Equals?

Нет, я считаю это вполне приемлемым. Однако вы не должны использовать такие объекты в качестве ключей в словаре / хеш-таблице, поскольку они изменяемы. См. Выше.

Я не знаю о C #, будучи относительным новичком к нему, но в Java, если вы переопределите equals (), вам также нужно переопределить hashCode () для поддержания контракта между ними (и наоборот) ... И java также есть такая же защелка 22; в основном заставляет вас использовать неизменяемые поля ... Но это проблема только для классов, которые используются в качестве хэш-ключа, а в Java есть альтернативные реализации для всех коллекций на основе хешей ... что, возможно, не так быстро, но они действительно эффективно позволяют использовать изменяемый объект в качестве ключа ... это просто (обычно) осуждается как "плохой дизайн".

И я чувствую побуждение указать на то, что эта фундаментальная проблема вечна ... Она существует с тех пор, как Адам был мальчишкой.

Я работал над кодом fortran, который старше меня (мне 36), который ломается при изменении имени пользователя (например, когда девушка выходит замуж или разводится ;-) ... Таким образом, инженерия, принятое решение было : «Метод» GetHashCode запоминает ранее вычисленный hashCode, пересчитывает hashCode (т.е. виртуальный маркер isDirty) и, если ключевые поля изменились, он возвращает null. Это приводит к тому, что кеш удаляет «грязного» пользователя (путем вызова другого GetPreviousHashCode), а затем кеш возвращает значение null, в результате чего пользователь перечитывает данные из базы данных. Интересный и стоящий взлом; даже если я сам так говорю ;-)

Я уступлю изменчивость (желательно только в угловых случаях) для доступа O (1) (желательно во всех случаях). Добро пожаловать в инжиниринг; страна осознанного компромисса.

Ваше здоровье. Кит.

Основная тема здесь - как лучше всего однозначно идентифицировать объекты. Вы упоминаете сериализацию / десериализацию, что важно, потому что в этом процессе теряется ссылочная целостность.

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

Для тестирования вполне разумно определить любые необходимые вам утверждения, обычно они определяются не в самом типе, а скорее как служебные методы в наборе тестов. Может быть, TestSuite.AssertEquals (MyClass, MyClass)?

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