Qual é a diferença entre IEquatable e apenas substituindo Object.Equals ()?

Quero que minha Foodclasse seja capaz de testar sempre que for igual a outra instância de Food. Mais tarde vou usá-lo em uma lista e quero usar seu List.Contains()método. Devo implementar IEquatable<Food>ou simplesmente substituir Object.Equals()? Do MSDN:

Esse método determina a igualdade usando o comparador de igualdade padrão, conforme definido pela implementação do objeto IEquatable.Equals no método T (o tipo de valores na lista).

Então, minha próxima pergunta é: quais funções / classes da estrutura .NET fazem uso Object.Equals()? Devo usá-lo em primeiro lugar?

O principal motivo é o desempenho. Quando os genéricos foram introduzidos no .NET 2.0 eles foram capazes de adicionar um monte de aulas puro, como List<T>, Dictionary<K,V>, HashSet<T>, etc. Estas estruturas fazem uso pesado de GetHashCodee Equals. Mas para tipos de valor, isso requer boxe. IEquatable<T>permite que uma estrutura implemente um Equalsmétodo fortemente tipado , para que nenhum boxe seja necessário. Desempenho muito melhor ao usar tipos de valor com coleções genéricas.

Os tipos de referência não se beneficiam tanto, mas a IEquatable<T>implementação permite evitar uma conversão da System.Objectqual pode fazer diferença se for chamada com frequência.

Conforme observado no blog de Jared Parson , você ainda deve implementar as substituições de objetos.

De acordo com o MSDN :

Se você implementar IEquatable<T>, também deverá substituir as implementações da classe base Object.Equals(Object)e GetHashCode para que seu comportamento seja consistente com o do IEquatable<T>.Equals método. Se você substituir Object.Equals(Object), sua implementação substituída também será chamada em chamadas para o Equals(System.Object, System.Object)método estático em sua classe. Isso garante que todas as invocações do Equalsmétodo retornem resultados consistentes.

Portanto, parece que não há diferença funcional real entre os dois, exceto que qualquer um pode ser chamado dependendo de como a classe é usada. Do ponto de vista do desempenho, é melhor usar a versão genérica porque não há penalidade de boxe / unboxing associada a ela.

Do ponto de vista lógico, também é melhor implementar a interface. Substituir o objeto realmente não diz a ninguém que sua classe é realmente equivalente. A substituição pode ser apenas uma classe do not nothing ou uma implementação superficial. Usar a interface diz explicitamente: "Ei, isso é válido para verificação de igualdade!" É apenas um design melhor.

Estendendo o que Josh disse com um exemplo prático. +1 para Josh - eu estava prestes a escrever o mesmo na minha resposta.

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

Dessa forma, tenho o método Equals () reutilizável que funciona imediatamente para todas as minhas classes derivadas.

Se chamarmos object.Equals, isso força o boxe caro em tipos de valor. Isso é indesejável em cenários sensíveis ao desempenho. A solução é usar IEquatable<T>.

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

A idéia por trás IEquatable<T>disso é que ele fornece o mesmo resultado, object.Equalsmas mais rapidamente. A restrição where T : IEquatable<T>deve ser usada com tipos genéricos, como abaixo.

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

caso contrário, ele se liga a slower object.Equals().