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