IEquatable和刚刚重写Object.Equals（）之间有什么区别？

Question

我希望我的Food类能够测试何时它等于另一个实例Food。稍后我将使用它来对付List，并且我想使用它的List.Contains()方法。我应该执行IEquatable<Food>还是只覆盖Object.Equals()？从MSDN：

此方法，使用默认的相等比较， 如由对象的 实现对于T （值的列表中的类型）的 IEquatable.Equals方法的定义由 确定平等。

所以我的下一个问题是：.NET框架的哪些函数/类使用Object.Equals()？我应该首先使用它吗？

Answer 1

主要原因是表现。当在.NET 2.0中引入泛型时，他们能够添加一堆整齐的类，如List<T>,Dictionary<K,V>,HashSet<T>等。这些结构大量使用GetHashCode和Equals。但对于价值类型，这需要拳击。 IEquatable<T>让一个结构实现强类型Equals方法，因此不需要装箱。因此，在使用泛型集合的值类型时性能会好得多。

参考类型没有太多好处，但IEquatable<T>实现允许您避免来自System.Object的强制转换，如果频繁调用它可能会产生影响。

虽然在Jared Parson's blog上指出，但你仍然必须实现Object overrides。

Answer 2

按照MSDN：的 Object.Equals(Object)和GetHashCode 使他们的行为是一致的 与该IEquatable(T).Equals 方法

如果实现IEquatable(T)，你 也应该覆盖基类 实现。如果您确实覆盖了 Object.Equals(Object)，那么您的类的静态Equals(System.Object, System.Object)方法中的调用 也会调用您的重写的 实现。 这确保所有调用 的Equals方法返回一致的 结果。

因此，似乎两者之间没有真正的功能差异，除非可以根据类的使用方式来调用。从性能角度来看，它更好地使用通用版本，因为不存在与其相关的装箱/拆箱处罚。

从逻辑的角度来看，实现接口也更好。重写对象并不能真正告诉任何人你的类实际上是可以相等的。重写可能只是一个无所事事的类或浅层实现。明确地使用接口说：“嘿，这个东西适用于平等检查！”这只是更好的设计。

Answer 3

扩展Josh说的一个实际例子。+1给Josh - 我正要在我的回答中写下同样的内容。

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（）方法是比较适合我的所有派生类的盒子的方法。