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

Question

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

Este método determina la igualdad de utilizando el 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).

Así que mi siguiente pregunta es: ¿qué funciones/clases del .NET framework hacen uso de Object.Equals()? ¿Debería usarlo en primer lugar?

Answer 1

La razón principal es el rendimiento. Cuando se introdujeron los genéricos en .NET 2.0, pudieron agregar un montón de clases geniales como List<T>, Dictionary<K,V>, HashSet<T>, etc. Estas estructuras hacen un uso intensivo de GetHashCode y Equals. Pero para los tipos de valores, esto requiere boxeo. IEquatable<T> permite a una estructura implementar un método fuertemente tipado Equals por lo que no se requiere boxeo. Por lo tanto, un rendimiento mucho mejor cuando se usan tipos de valores con colecciones genéricas.

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

Sin embargo, como se indicó en Jared Parson's blog, debe implementar las anulaciones de objeto.

Answer 2

De acuerdo con los MSDN:

Si implementa IEquatable(T), que también debe sustituir la clase de base de implementaciones de Object.Equals(Object) y GetHashCode por lo que su comportamiento es consistente con la del método IEquatable(T).Equals . Si sobrescribe Object.Equals(Object), su implementación reemplazada también se llama en las llamadas al método estático Equals(System.Object, System.Object) en su clase. Esto garantiza que todas las invocaciones de el método Equals devuelvan resultados consistentes .

Parece que no hay una diferencia funcional real entre los dos, excepto que cualquiera podría llamarse dependiendo de cómo se usa la clase. Desde el punto de vista del rendimiento, es mejor utilizar la versión genérica porque no hay una penalización de box/unboxing asociada.

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 equitativa. La anulación puede ser simplemente 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.

Answer 3

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

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, he re-utilizables() método que funciona fuera de la caja para todas mis clases derivadas.