Sự khác biệt giữa IEquitable và chỉ ghi đè Object.Equals () là gì?

Tôi muốn Foodlớp của tôi có thể kiểm tra bất cứ khi nào nó bằng với một thể hiện khác Food. Sau này tôi sẽ sử dụng nó để chống lại Danh sách và tôi muốn sử dụng List.Contains()phương thức của nó . Tôi nên thực hiện IEquatable<Food>hay chỉ ghi đè Object.Equals()? Từ MSDN:

Phương thức này xác định đẳng thức bằng cách sử dụng trình so sánh đẳng thức mặc định, như được xác định bởi việc thực hiện phương thức IEquitable.Equals của đối tượng cho T (loại giá trị trong danh sách).

Vì vậy, câu hỏi tiếp theo của tôi là: các chức năng / lớp nào của .NET framework sử dụng Object.Equals()? Tôi có nên sử dụng nó ở nơi đầu tiên?

Lý do chính là hiệu suất. Khi Generics đã được giới thiệu trong .NET 2.0 họ đã có thể để thêm một loạt các lớp học gọn gàng như List<T>, Dictionary<K,V>, HashSet<T>, vv Những công trình sử dụng nhiều của GetHashCodevà Equals. Nhưng đối với các loại giá trị này yêu cầu quyền anh. IEquatable<T>cho phép một cấu trúc thực hiện một Equalsphương pháp gõ mạnh để không cần đấm bốc. Do đó hiệu suất tốt hơn nhiều khi sử dụng các loại giá trị với các bộ sưu tập chung.

Các kiểu tham chiếu không mang lại lợi ích nhiều nhưng việc IEquatable<T>triển khai cho phép bạn tránh được một diễn viên System.Objectcó thể tạo ra sự khác biệt nếu nó được gọi thường xuyên.

Như đã lưu ý trên blog của Jared Parson , bạn vẫn phải thực hiện ghi đè Đối tượng.

Theo MSDN :

Nếu bạn triển khai IEquatable<T>, bạn cũng nên ghi đè các triển khai của lớp cơ sở Object.Equals(Object)và GetHashCode để hành vi của chúng phù hợp với IEquatable<T>.Equals phương thức. Nếu bạn thực hiện ghi đè Object.Equals(Object), việc thực hiện ghi đè của bạn cũng được gọi trong các cuộc gọi đến Equals(System.Object, System.Object)phương thức tĩnh trên lớp của bạn. Điều này đảm bảo rằng tất cả các yêu cầu của Equalsphương thức trả về kết quả nhất quán.

Vì vậy, có vẻ như không có sự khác biệt về chức năng thực sự giữa hai loại trừ việc có thể được gọi tùy thuộc vào cách sử dụng lớp. Từ quan điểm hiệu suất, tốt hơn là sử dụng phiên bản chung vì không có hình phạt đấm bốc / bỏ hộp liên quan đến nó.

Từ quan điểm logic, tốt hơn là thực hiện giao diện. Ghi đè đối tượng không thực sự nói với ai rằng lớp của bạn thực sự tương đương. Việc ghi đè có thể chỉ là một lớp không làm gì hoặc thực hiện nông. Sử dụng giao diện rõ ràng nói, "Này, điều này là hợp lệ để kiểm tra sự bình đẳng!" Nó chỉ là thiết kế tốt hơn.

Mở rộng những gì Josh nói với một ví dụ thực tế. +1 cho Josh - Tôi sắp viết tương tự trong câu trả lời của mình.

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

Bằng cách này, tôi có phương thức Equals () có thể sử dụng lại hoạt động ngoài hộp cho tất cả các lớp dẫn xuất của tôi.

Nếu chúng ta gọi object.Equals, nó buộc phải đóng hộp đắt tiền về các loại giá trị. Điều này là không mong muốn trong các kịch bản nhạy cảm hiệu suất. Giải pháp là sử dụng IEquatable<T>.

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

Ý tưởng đằng sau IEquatable<T>là nó cho kết quả tương tự object.Equalsnhưng nhanh hơn. Các ràng buộc where T : IEquatable<T>phải được sử dụng với các loại chung chung như dưới đây.

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

mặt khác, nó liên kết với slower object.Equals().