В чем разница между использованием IEqualityComparer и переопределением Equals/GethashCode?

Когда вы переопределяете Equals и GetHashCode, вы меняете способ, которым объект будет определять, равен ли он другому. И примечание: если вы сравниваете объекты с помощью оператора ==, он не будет иметь такого же поведения, как Equals, если только вы не переопределите оператор.

Сделав это, вы изменили поведение для одного класса, что, если вам нужна такая же логика для других классов? Если вам нужно "общее сравнение". Вот почему у вас есть IEqualityComparer.

Посмотрите на этот пример:

interface ICustom
{
    int Key { get; set; }
}
class Custom : ICustom
{
    public int Key { get; set; }
    public int Value { get; set; }
}
class Another : ICustom
{
    public int Key { get; set; }
}

class DicEqualityComparer : IEqualityComparer<ICustom>
{
    public bool Equals(ICustom x, ICustom y)
    {
        return x.Key == y.Key;
    }

    public int GetHashCode(ICustom obj)
    {
        return obj.Key;
    }
}

У меня есть два разных класса, оба могут использовать один и тот же компаратор.

var a = new Custom { Key = 1, Value = 2 };
var b = new Custom { Key = 1, Value = 2 };
var c = new Custom { Key = 2, Value = 2 };
var another = new Another { Key = 2 };

var d = new Dictionary<ICustom, string>(new DicEqualityComparer());

d.Add(a, "X");
// d.Add(b, "X"); // same key exception
d.Add(c, "X");
// d.Add(another, "X"); // same key exception

Обратите внимание, что мне не пришлось переопределять Equals, GetHashCode ни в одном из классов. Я могу использовать этот компаратор в любом объекте, реализующем ICustom, без необходимости переписывать логику сравнения. Я также могу сделать IEqualityComparer для «родительского класса» и использовать его в классах, которые наследуются. У меня может быть компаратор, который будет вести себя по-другому, я могу сделать один для сравнения Value вместо Key.

Таким образом, IEqualityComparer обеспечивает большую гибкость, и вы можете реализовывать общие решения.

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

По сути, это то же самое для этой цели с одной тонкой разницей. В вашем первом примере вы переопределяете Equals, используя параметр типа Object, а затем должны привести его к Customer, однако во втором примере вы можете иметь параметр типа Customer, что означает, что нет необходимости выполнять приведение.

Это означает, что переопределение Equals позволяет сравнивать два объекта разных типов (что может понадобиться в определенных обстоятельствах), однако реализация IEqualityComparer не дает этой свободы (что также может понадобиться в определенных обстоятельствах).

Есть много случаев, когда может потребоваться Dictionary местоположение объектов с использованием чего-то другого, кроме 100% эквивалентности. В качестве простого примера можно захотеть иметь словарь, который соответствует без учета регистра. Один из способов добиться этого — преобразовать строки в каноническую форму верхнего регистра перед сохранением их в словаре или выполнением поиска. Альтернативный подход состоит в том, чтобы снабдить словарь IEqualityComparer<string>, который будет вычислять хэш-коды и проверять равенство в какой-то функции, не зависящей от регистра. Есть некоторые обстоятельства, когда преобразование строк в каноническую форму и использование этой формы, когда это возможно, будет более эффективным, но есть и другие, когда более эффективно хранить строку только в ее исходной форме. Одна функция, которую я хотел бы иметь в .NET, которая повысила бы полезность таких словарей, была бы средством запроса фактического объекта ключа, связанного с данным ключом (так что, если бы словарь содержал строку "WowZo" в качестве ключа, можно было бы найти "wowzo" и получить "WowZo"; к сожалению, единственный способ получить настоящий ключевой объект, если TValue не содержит избыточной ссылки на него, — это перечислить всю коллекцию).

Другой сценарий, в котором может быть полезно иметь альтернативные средства сравнения, — это когда объект содержит ссылку на экземпляр изменяемого типа, но никогда не подвергает этот экземпляр чему-либо, что может его изменить. В общем, два экземпляра int[], которые содержат одну и ту же последовательность значений, не будут взаимозаменяемыми, поскольку вполне возможно, что в будущем один или оба из них могут быть изменены для хранения разных значений. С другой стороны, если словарь будет использоваться для хранения и поиска значений int[], каждое из которых будет единственной ссылкой где-либо во вселенной на экземпляр int[], и если ни один из экземпляров не будет изменен или открыт для внешних код, может быть полезно рассматривать как равные экземпляры массива, которые содержат идентичные последовательности значений. Поскольку Array.Equals проверяет строгую эквивалентность (равенство ссылок), необходимо использовать какие-то другие средства проверки массивов на эквивалентность.