В чем разница между IEquatable и просто переопределением Object.Equals ()?

Основная причина - производительность. Когда в .NET 2.0 были представлены обобщенные элементы, они смогли добавить кучу аккуратных классов, таких как List<T>, Dictionary<K,V>, HashSet<T> и т. Д. В этих структурах интенсивно используются GetHashCode и Equals. Но для ценностных типов это требовало бокса. IEquatable<T> позволяет структуре реализовать строго типизированный Equals метод, поэтому упаковка не требуется. Таким образом, производительность намного выше при использовании типов значений с универсальными коллекциями.

Ссылочные типы не имеют такой выгоды, но реализация IEquatable<T> позволяет избежать преобразования из System.Object, которое может иметь значение, если оно часто вызывается.

Как указано на блог Джареда Парсона, однако вы должны по-прежнему реализовать стандартные Object.Equals и Object.GetHashcode переопределения.

Согласно MSDN:

Если вы реализуете IEquatable<T>, вы также должны переопределить реализации базового класса Object.Equals(Object) и GetHashCode, чтобы их поведение согласовывалось с поведением метода IEquatable<T>.Equals. Если вы действительно переопределяете Object.Equals(Object), ваша переопределенная реализация также вызывается в вызовах статического метода Equals(System.Object, System.Object) в вашем классе. Это гарантирует, что все вызовы метода Equals возвращают согласованные результаты.

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

С логической точки зрения интерфейс тоже лучше реализовать. Переопределение объекта на самом деле никому не говорит о том, что ваш класс действительно эквивалентен. Переопределение может быть просто классом ничего не делать или поверхностной реализацией. Использование интерфейса явно говорит: «Эй, эта штука подходит для проверки равенства!» Это просто лучший дизайн.

Дополним сказанное Джошем практическим примером. +1 Джошу - я собирался написать то же самое в своем ответе.

public abstract class EntityBase : IEquatable<EntityBase>
{
    public EntityBase() { }

    #region IEquatable<EntityBase> Members

    public bool Equals(EntityBase other)
    {
        //Generic implementation of equality using reflection on derived class instance.
        return true;
    }

    public override bool Equals(object obj)
    {
        return this.Equals(obj as EntityBase);
    }

    #endregion
}

public class Author : EntityBase
{
    public Author() { }
}

public class Book : EntityBase
{
    public Book() { }
}

Таким образом, у меня есть повторно используемый метод Equals (), который работает "из коробки" для всех моих производных классов.

Если мы вызываем object.Equals, это вынуждает к дорогостоящему боксу по типам значений. Это нежелательно в сценариях, чувствительных к производительности. Решение - использовать IEquatable<T>.

public interface IEquatable<T>
{
  bool Equals (T other);
}

Идея IEquatable<T> в том, что он дает тот же результат, что и object.Equals, но быстрее. Ограничение where T : IEquatable<T> должно использоваться с универсальными типами, как показано ниже.

public class Test<T> where T : IEquatable<T>
{
  public bool IsEqual (T a, T b)
  {
    return a.Equals (b); // No boxing with generic T
  }
}

в противном случае он привязывается к slower object.Equals().