¿Cuál es la diferencia entre IEquatable y simplemente anular Object.Equals ()?

Quiero que mi Foodclase pueda evaluar cuando sea igual a otra instancia de Food. Más tarde lo usaré contra una Lista, y quiero usar su List.Contains()método. ¿Debo implementar IEquatable<Food>o simplemente anular Object.Equals()? De MSDN:

Este método determina la igualdad mediante el uso del comparador de igualdad predeterminado, según lo definido por la implementación del objeto del método IEquatable.Equals para T (el tipo de valores en la lista).

Entonces mi siguiente pregunta es: ¿qué funciones / clases de .NET Framework utilizan Object.Equals()? ¿Debo usarlo en primer lugar?

La razón principal es el rendimiento. Cuando se introdujeron los genéricos en .NET 2.0 que fueron capaces de añadir un montón de clases ordenadas tales como List<T>, Dictionary<K,V>, HashSet<T>, etc. Estas estructuras hacen un uso intensivo de GetHashCodey Equals. Pero para los tipos de valor esto requería boxeo. IEquatable<T>permite que una estructura implemente un Equalsmétodo fuertemente tipado para que no se requiera boxeo. Por lo tanto, un rendimiento mucho mejor cuando se utilizan tipos de valor con colecciones genéricas.

Los tipos de referencia no se benefician tanto, pero la IEquatable<T>implementación le permite evitar un reparto desde el System.Objectque puede marcar la diferencia si se llama con frecuencia.

Sin embargo, como se señaló en el blog de Jared Parson , aún debe implementar las anulaciones de objetos.

Según el MSDN :

Si implementa IEquatable<T>, también debe anular las implementaciones de clase base de Object.Equals(Object)y GetHashCode para que su comportamiento sea coherente con el del IEquatable<T>.Equals método. Si anula Object.Equals(Object), su implementación anulada también se llama en llamadas al Equals(System.Object, System.Object)método estático en su clase. Esto asegura que todas las invocaciones del Equalsmétodo devuelvan resultados consistentes.

Por lo tanto, parece que no hay una diferencia funcional real entre los dos, excepto que cualquiera podría llamarse dependiendo de cómo se use la clase. Desde el punto de vista del rendimiento, es mejor usar la versión genérica porque no hay penalización de boxeo / desempaquetado asociada con ella.

Desde un punto de vista lógico, también es mejor implementar la interfaz. Anular el objeto realmente no le dice a nadie que su clase es realmente equiparable. La anulación puede ser una clase de no hacer nada o una implementación superficial. El uso de la interfaz dice explícitamente: "¡Oye, esto es válido para la verificación de igualdad!" Es solo un mejor diseño.

Extendiendo lo que Josh dijo con un ejemplo práctico. +1 a Josh: estaba a punto de escribir lo mismo en mi respuesta.

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() { }
}

De esta manera, tengo el método Equals () reutilizable que funciona de forma inmediata para todas mis clases derivadas.

Si llamamos object.Equals, obliga al costoso boxeo en los tipos de valor. Esto no es deseable en escenarios sensibles al rendimiento. La solución es usar IEquatable<T>.

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

La idea detrás IEquatable<T>es que da el mismo resultado object.Equalspero más rápido. La restricción where T : IEquatable<T>debe usarse con tipos genéricos como a continuación.

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

de lo contrario, se une a slower object.Equals().