Tại sao điều quan trọng là ghi đè GetHashCode khi phương thức Equals bị ghi đè?

Cho lớp sau

public class Foo
{
    public int FooId { get; set; }
    public string FooName { get; set; }

    public override bool Equals(object obj)
    {
        Foo fooItem = obj as Foo;

        if (fooItem == null) 
        {
           return false;
        }

        return fooItem.FooId == this.FooId;
    }

    public override int GetHashCode()
    {
        // Which is preferred?

        return base.GetHashCode();

        //return this.FooId.GetHashCode();
    }
}

Tôi đã ghi đè Equalsphương thức vì Foobiểu diễn một hàng cho Foobảng s. Đó là phương pháp ưa thích để ghi đè GetHashCode?

Tại sao nó quan trọng để ghi đè GetHashCode?

Có, điều quan trọng là nếu mục của bạn sẽ được sử dụng làm khóa trong từ điển, hoặc HashSet<T>, v.v. - vì mục này được sử dụng (trong trường hợp không có tùy chỉnh IEqualityComparer<T>) để nhóm các mục vào nhóm. Nếu hash-mã cho hai mục không phù hợp, họ có thể không bao giờ được coi là bằng nhau ( Equals sẽ chỉ đơn giản là không bao giờ được gọi là).

Phương thức GetHashCode () sẽ phản ánh Equalslogic; các quy tắc là:

• nếu hai thứ bằng nhau ( Equals(...) == true) thì chúng phải trả về cùng một giá trị choGetHashCode()
• nếu GetHashCode()bằng nhau, thì không cần thiết phải giống nhau; đây là một sự va chạm, và Equalssẽ được gọi để xem đó có phải là một sự bình đẳng thực sự hay không.

Trong trường hợp này, có vẻ như " return FooId;" là một GetHashCode()triển khai phù hợp . Nếu bạn đang kiểm tra nhiều thuộc tính, thông thường kết hợp chúng bằng cách sử dụng mã như dưới đây, để giảm va chạm chéo (nghĩa là new Foo(3,5)có mã băm khác nhau new Foo(5,3)):

unchecked // only needed if you're compiling with arithmetic checks enabled
{ // (the default compiler behaviour is *disabled*, so most folks won't need this)
    int hash = 13;
    hash = (hash * 7) + field1.GetHashCode();
    hash = (hash * 7) + field2.GetHashCode();
    ...
    return hash;
}

Ồ - để thuận tiện, bạn cũng có thể xem xét việc cung cấp ==và !=vận hành khi ghi đè Equalsvà GetHashCode.

Một minh chứng về những gì xảy ra khi bạn nhận được điều này là ở đây .

Thật sự rất khó để thực hiện GetHashCode()chính xác bởi vì, ngoài các quy tắc mà Marc đã đề cập, mã băm không nên thay đổi trong suốt vòng đời của một đối tượng. Do đó, các trường được sử dụng để tính mã băm phải là bất biến.

Cuối cùng tôi đã tìm thấy một giải pháp cho vấn đề này khi tôi làm việc với NHibernate. Cách tiếp cận của tôi là tính mã băm từ ID của đối tượng. ID chỉ có thể được đặt mặc dù là hàm tạo nên nếu bạn muốn thay đổi ID, điều này rất khó xảy ra, bạn phải tạo một đối tượng mới có ID mới và do đó là mã băm mới. Cách tiếp cận này hoạt động tốt nhất với GUID vì bạn có thể cung cấp hàm tạo không tham số tạo ngẫu nhiên ID.

Bằng cách ghi đè Bằng, về cơ bản, bạn nói rằng bạn là người hiểu rõ hơn về cách so sánh hai trường hợp của một loại nhất định, do đó bạn có thể là ứng cử viên tốt nhất để cung cấp mã băm tốt nhất.

Đây là một ví dụ về cách ReSharper viết hàm GetHashCode () cho bạn:

public override int GetHashCode()
{
    unchecked
    {
        var result = 0;
        result = (result * 397) ^ m_someVar1;
        result = (result * 397) ^ m_someVar2;
        result = (result * 397) ^ m_someVar3;
        result = (result * 397) ^ m_someVar4;
        return result;
    }
}

Như bạn có thể thấy, nó chỉ cố gắng đoán mã băm tốt dựa trên tất cả các trường trong lớp, nhưng vì bạn biết phạm vi giá trị hoặc miền của đối tượng của bạn, bạn vẫn có thể cung cấp mã tốt hơn.

Xin đừng quên kiểm tra tham số obj nullkhi ghi đè Equals(). Và cũng so sánh các loại.

public override bool Equals(object obj)
{
    Foo fooItem = obj as Foo;

    if (fooItem == null)
    {
       return false;
    }

    return fooItem.FooId == this.FooId;
}

Lý do cho điều này là: Equalsphải trả về sai khi so sánh với null. Xem thêm http://msdn.microsoft.com/en-us/l Library / bsc2ak47.aspx

Làm thế nào về:

public override int GetHashCode()
{
    return string.Format("{0}_{1}_{2}", prop1, prop2, prop3).GetHashCode();
}

Giả sử hiệu suất không phải là một vấn đề :)

Chúng tôi có hai vấn đề để đối phó.

1. Bạn không thể cung cấp hợp lý GetHashCode()nếu bất kỳ trường nào trong đối tượng có thể được thay đổi. Ngoài ra thường thì một đối tượng sẽ KHÔNG BAO GIỜ được sử dụng trong một bộ sưu tập phụ thuộc vào GetHashCode(). Vì vậy, chi phí thực hiện GetHashCode()thường không đáng, hoặc không thể.

2. Nếu ai đó đặt đối tượng của bạn vào một bộ sưu tập gọi GetHashCode()và bạn đã ghi đè Equals()mà không thực hiện GetHashCode()hành vi đúng cách, người đó có thể mất nhiều ngày để theo dõi vấn đề.

Do đó theo mặc định tôi làm.

public class Foo
{
    public int FooId { get; set; }
    public string FooName { get; set; }

    public override bool Equals(object obj)
    {
        Foo fooItem = obj as Foo;

        if (fooItem == null)
        {
           return false;
        }

        return fooItem.FooId == this.FooId;
    }

    public override int GetHashCode()
    {
        // Some comment to explain if there is a real problem with providing GetHashCode() 
        // or if I just don't see a need for it for the given class
        throw new Exception("Sorry I don't know what GetHashCode should do for this class");
    }
}

Đó là bởi vì khung công tác yêu cầu hai đối tượng giống nhau phải có cùng mã băm. Nếu bạn ghi đè phương thức bằng để thực hiện so sánh đặc biệt của hai đối tượng và hai đối tượng được coi là giống nhau bởi phương thức, thì mã băm của hai đối tượng cũng phải giống nhau. (Từ điển và Hashtables dựa trên nguyên tắc này).

Chỉ cần thêm vào câu trả lời trên:

Nếu bạn không ghi đè Bằng thì hành vi mặc định là tham chiếu của các đối tượng được so sánh. Điều tương tự cũng áp dụng cho mã băm - việc cấy ghép mặc định thường dựa trên địa chỉ bộ nhớ của tham chiếu. Bởi vì bạn đã ghi đè Bằng, điều đó có nghĩa là hành vi đúng là so sánh bất cứ điều gì bạn đã thực hiện trên Bằng và không phải là các tham chiếu, vì vậy bạn nên làm tương tự cho mã băm.

Các khách hàng của lớp của bạn sẽ mong muốn mã băm có logic tương tự như phương thức bằng, ví dụ như các phương thức linq sử dụng IEqualityComparer trước tiên so sánh các mã băm và chỉ khi chúng bằng nhau, chúng sẽ so sánh phương thức Equals () có thể đắt hơn để chạy, nếu chúng tôi không triển khai mã băm, đối tượng bằng nhau có thể sẽ có các mã băm khác nhau (vì chúng có địa chỉ bộ nhớ khác nhau) và sẽ được xác định sai là không bằng nhau (Bằng (thậm chí sẽ không được nhấn).

Ngoài ra, ngoại trừ vấn đề bạn có thể không tìm thấy đối tượng của mình nếu bạn đã sử dụng nó trong từ điển (vì nó được chèn bởi một mã băm và khi bạn tìm nó, mã băm mặc định có thể sẽ khác và một lần nữa là Equals () Thậm chí sẽ không được gọi, như Marc Gravell giải thích trong câu trả lời của anh ấy, bạn cũng đưa ra vi phạm khái niệm từ điển hoặc hàm băm không cho phép các khóa giống hệt nhau - bạn đã tuyên bố rằng các đối tượng đó về cơ bản là giống nhau khi bạn vượt qua Equals để bạn không Không muốn cả hai là các khóa khác nhau trên cấu trúc dữ liệu, giả sử có một khóa duy nhất. Nhưng vì chúng có mã băm khác nhau, khóa "giống nhau" sẽ được chèn dưới dạng khác nhau.

Mã băm được sử dụng cho các bộ sưu tập dựa trên hàm băm như Dictionary, Hashtable, Hashset, v.v ... Mục đích của mã này là rất nhanh sắp xếp trước đối tượng cụ thể bằng cách đặt nó vào nhóm cụ thể (nhóm). Việc sắp xếp trước này giúp ích rất nhiều trong việc tìm kiếm đối tượng này khi bạn cần lấy lại từ bộ sưu tập băm vì mã phải tìm kiếm đối tượng của bạn chỉ trong một nhóm thay vì trong tất cả các đối tượng mà nó chứa. Việc phân phối mã băm tốt hơn (tính duy nhất tốt hơn) càng nhanh hơn. Trong tình huống lý tưởng nơi mỗi đối tượng có một mã băm duy nhất, việc tìm kiếm nó là một hoạt động O (1). Trong hầu hết các trường hợp, nó tiếp cận O (1).

Nó không nhất thiết phải quan trọng; nó phụ thuộc vào kích thước của các bộ sưu tập của bạn và các yêu cầu về hiệu suất của bạn và liệu lớp của bạn sẽ được sử dụng trong thư viện nơi bạn có thể không biết các yêu cầu về hiệu suất. Tôi thường biết kích thước bộ sưu tập của mình không lớn lắm và thời gian của tôi có giá trị hơn một vài phần triệu hiệu suất đạt được bằng cách tạo mã băm hoàn hảo; vì vậy (để thoát khỏi cảnh báo khó chịu của trình biên dịch) Tôi chỉ cần sử dụng:

   public override int GetHashCode()
   {
      return base.GetHashCode();
   }

(Tất nhiên tôi cũng có thể sử dụng #pragma để tắt cảnh báo nhưng tôi thích cách này hơn.)

Khi bạn đang ở trong vị trí mà bạn làm cần hiệu suất so với tất cả các vấn đề được đề cập bởi những người khác ở đây áp dụng, tất nhiên. Quan trọng nhất - nếu không, bạn sẽ nhận được kết quả sai khi truy xuất các mục từ bộ băm hoặc từ điển: mã băm không được thay đổi theo thời gian sống của một đối tượng (chính xác hơn, trong thời gian bất cứ khi nào cần mã băm, chẳng hạn như trong khi một khóa trong từ điển): ví dụ, sau đây là sai vì Giá trị là công khai và do đó có thể được thay đổi bên ngoài thành lớp trong suốt thời gian tồn tại của cá thể, vì vậy bạn không được sử dụng nó làm cơ sở cho mã băm:

   class A
   {
      public int Value;

      public override int GetHashCode()
      {
         return Value.GetHashCode(); //WRONG! Value is not constant during the instance's life time
      }
   }    

Mặt khác, nếu Giá trị không thể thay đổi, bạn có thể sử dụng:

   class A
   {
      public readonly int Value;

      public override int GetHashCode()
      {
         return Value.GetHashCode(); //OK  Value is read-only and can't be changed during the instance's life time
      }
   }

Bạn phải luôn đảm bảo rằng nếu hai đối tượng bằng nhau, như được định nghĩa bởi Equals (), chúng sẽ trả về cùng mã băm. Như một số trạng thái bình luận khác, về lý thuyết, điều này không bắt buộc nếu đối tượng sẽ không bao giờ được sử dụng trong một thùng chứa dựa trên hàm băm như Hashset hoặc Dictionary. Tôi sẽ khuyên bạn luôn luôn tuân theo quy tắc này. Lý do đơn giản là vì quá dễ dàng để ai đó thay đổi bộ sưu tập từ loại này sang loại khác với mục đích tốt là thực sự cải thiện hiệu suất hoặc chỉ truyền đạt ngữ nghĩa mã theo cách tốt hơn.

Ví dụ: giả sử chúng tôi giữ một số đối tượng trong Danh sách. Sau đó, một người nào đó thực sự nhận ra rằng Hashset là một lựa chọn tốt hơn nhiều vì các đặc điểm tìm kiếm tốt hơn chẳng hạn. Đây là khi chúng ta có thể gặp rắc rối. Danh sách sẽ sử dụng bên trong bộ so sánh đẳng thức mặc định cho loại có nghĩa là Bằng trong trường hợp của bạn trong khi Hashset sử dụng GetHashCode (). Nếu hai người cư xử khác nhau, chương trình của bạn cũng vậy. Và hãy nhớ rằng các vấn đề như vậy không phải là dễ dàng nhất để khắc phục sự cố.

Tôi đã tóm tắt hành vi này với một số cạm bẫy GetHashCode () khác trong một bài đăng trên blog nơi bạn có thể tìm thấy các ví dụ và giải thích thêm.

Theo .NET 4.7phương pháp ghi đè ưa thích GetHashCode()được hiển thị dưới đây. Nếu nhắm mục tiêu các phiên bản .NET cũ hơn, hãy bao gồm gói nuget System.ValueTuple .

// C# 7.0+
public override int GetHashCode() => (FooId, FooName).GetHashCode();

Về mặt hiệu suất, phương pháp này sẽ vượt trội so với hầu hết các triển khai mã băm tổng hợp . Các ValueTuple là một structvì vậy sẽ không có bất kỳ rác, và các thuật toán cơ bản là nhanh như nó được.

Theo hiểu biết của tôi, GetHashCode () ban đầu trả về địa chỉ bộ nhớ của đối tượng, do đó, điều cần thiết là ghi đè lên nó nếu bạn muốn so sánh hai đối tượng khác nhau.

EDITED: Điều đó không chính xác, phương thức GetHashCode () ban đầu không thể đảm bảo sự bằng nhau của 2 giá trị. Mặc dù các đối tượng bằng nhau trả về cùng mã băm.

Dưới đây sử dụng sự phản chiếu dường như là một lựa chọn tốt hơn khi xem xét các thuộc tính công cộng vì với điều này, bạn không phải lo lắng về việc thêm / xóa các thuộc tính (mặc dù kịch bản không phổ biến lắm). Điều này tôi thấy là cũng hoạt động tốt hơn (So với thời gian sử dụng đồng hồ bấm giờ Diagonistic).

    public int getHashCode()
    {
        PropertyInfo[] theProperties = this.GetType().GetProperties();
        int hash = 31;
        foreach (PropertyInfo info in theProperties)
        {
            if (info != null)
            {
                var value = info.GetValue(this,null);
                if(value != null)
                unchecked
                {
                    hash = 29 * hash ^ value.GetHashCode();
                }
            }
        }
        return hash;  
    }