В FxCop есть такое правило Override GetHashCode on overriding Equals, переопределяйте GetHashCode переопределяя Equals. Так вот с этим правилом связан подводный камень. В Rule Description там написано об этом но как на мой взгляд не совсем ясно.
Это связано с принципом работы HashTable и Dictionary в .NET, и для того чтобы сравнение производилось верно при переопределении Equals необходимо обязательно переопределить GetHashCode в зависимости от тех данных которые учувствуют в сравнении. Иначе Equals просто не будет вызван, хотя многие разработчики ожидают что он будет вызыватся всегда. Equals вызывается только тогда когда GetHashCode возвращает одинаковые значения, что как было сказано выше, связано с принципом работы словарей и хеш-таблиц, для того чтобы разрешить коллизии в хеш-таблице.
С другой стороны на такие неправильные выводы вполне возможно наталкивает поведение System.Object метод GetHashCode которого возвращает значения, которые не зависят от данных хранящихся в объекте и возвращает разные хеш-коды для одинаковых объектов.
Эту распространенную ошибку можно рассмотреть на примере:
Есть CustomType, по сути в нем два поля Name и Age:
public class NamesComparer : IEqualityComparer<CustomType>
{
#region IEqualityComparer<CustomType> Members
public bool Equals(CustomType x, CustomType y)
{
return string.Equals(x.Name, y.Name);
}
public int GetHashCode(CustomType obj)
{
// распространенная ошибка, неверно
return obj.GetHashCode();
}
#endregion
}
[DebuggerDisplay("Name: {Name}, age: {Age}")]
public class CustomType : IEqualityComparer<CustomType>
{
public CustomType()
{
}
public CustomType(string name, int age)
{
Name = name;
Age = age;
}
public int Age { get; set; }
public string Name { get; set; }
public override bool Equals(CustomType x, CustomType y)
{
return string.Equals(x.Name, y.Name);
}
public override int GetHashCode(CustomType obj)
{
// распространенная ошибка, неверно
return obj.GetHashCode();
}
}
* This source code was highlighted with Source Code Highlighter.Есть два списка:
CustomType[] customTypeShortList = new[] {
new CustomType("reno", 1),
new CustomType("opel", 2) };
CustomType[] customTypeLongList = new[] {
new CustomType("reno", 3),
new CustomType("opel", 1),
new CustomType("subaru", 1),
new CustomType("toyota", 5),
new CustomType("nissan", 4),
new CustomType("audi", 3)};
Найдем их пересечение через linq оператор Intersect. Так как мы работаем с составным не примитивным типом необходимо будет указать IEqualityComparer для этого типа:
IEnumerable<CustomType> intersect = customTypeLongList
.Intersect(customTypeShortList, new NamesComparer());
В результате ожидаем получить в списке intersect два значения: reno - 3 и opel – 1. Но мы их не получим, потому что GetHashCode в CustomType имплементирован не верно. Так как у каждого объекта в целом разные хеш коды то метод Equals даже не будет вызываться.
Правильной имплементацией в данном случае будет вариант:
public int GetHashCode(CustomType obj)
{
return obj.Name.GetHashCode();
}
а можно попробовать и такой вариант, он конечно не верный но пересечение отработает правильно, так как Equals будет вызываться всегда.
public int GetHashCode(CustomType obj)
{
// также неверно, из-за того что это ударит по производительности
return string.Empty.GetHashCode();
}
Важно также не перепутать имплементацию GetHashCode из IEqualityComparer, а не переопределение GetHashCode объекта, т.к. во втором случае словарь будет работать неправильно.
Следовательно при имплементации Equals обязательно необходимо имплементировать GetHashCode причем с учетом тех данных что принимают участие в сравнение в Equals. В противном случае Equals может даже и не вызываться.
Так как много людей попадается на этот подводный камень, я и решил написать об этом.
