Equals 메서드를 재정의 할 때 GetHashCode를 재정의해야하는 이유는 무엇입니까?

다음 클래스를 감안할 때

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

s 테이블 의 행을 나타 내기 Equals때문에 메서드를 재정의했습니다 . ? 를 재정의하는 데 선호되는 방법은 무엇입니까?FooFooGetHashCode

대체하는 것이 왜 중요 GetHashCode합니까?

예, 항목을 사전에 키로 사용하는 경우 또는 HashSet<T>등 이 중요합니다 . 사용자 지정이없는 경우 IEqualityComparer<T>항목을 버킷으로 그룹화 하는 데 사용되기 때문 입니다. 두 항목의 해시 코드가 일치하지 않으면 결코 같은 것으로 간주 되지 않을 수 있습니다 ( 같음 은 단순히 호출되지 않습니다).

GetHashCode () 메소드는 반영해야 Equals로직; 규칙은 다음과 같습니다.

• 두 가지가 같으면 ( Equals(...) == true) 동일한 값을 반환 해야합니다.GetHashCode()
• 경우 (가) GetHashCode()와 동일하다, 그 것이다 되지 들이 동일 할 필요; 이것은 충돌이며 Equals실제 평등인지 확인하기 위해 호출됩니다.

이 경우 " return FooId;"가 적합한 GetHashCode()구현 인 것 같습니다 . 여러 속성을 테스트하는 경우 대각선 충돌을 줄이기 위해 아래와 같은 코드를 사용하여 속성을 결합하는 것이 일반적입니다 (예 : new Foo(3,5)와 다른 해시 코드를 가짐 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;
}

오 - 편의를 위해, 당신은 또한 제공 고려해 볼 수 있습니다 ==및 !=운영자가 오버라이드 (override) 할 때 Equals와 GetHashCode.

이 오류가 발생하면 어떻게되는지 보여주는 데모가 여기 있습니다 .

GetHashCode()Marc가 이미 언급 한 규칙 외에도 해시 코드가 객체의 수명 동안 변경되지 않아야하기 때문에 실제로 올바르게 구현하기가 매우 어렵습니다 . 따라서 해시 코드를 계산하는 데 사용되는 필드는 변경 불가능해야합니다.

NHibernate와 함께 일할 때 마침내이 문제에 대한 해결책을 찾았습니다. 내 접근 방식은 객체의 ID에서 해시 코드를 계산하는 것입니다. ID는 생성자를 통해서만 설정할 수 있으므로 ID를 변경하려는 경우 매우 드물지만 새 ID를 가진 새 객체와 새 해시 코드를 만들어야합니다. 이 방법은 임의로 ID를 생성하는 매개 변수가없는 생성자를 제공 할 수 있으므로 GUID에 가장 적합합니다.

Equals를 재정의하면 기본적으로 자신이 주어진 유형의 두 인스턴스를 비교하는 방법을 더 잘 알고 있다고 주장하므로 최고의 해시 코드를 제공하는 가장 좋은 후보가 될 수 있습니다.

다음은 ReSharper가 GetHashCode () 함수를 작성하는 방법의 예입니다.

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;
    }
}

보시다시피 클래스의 모든 필드를 기반으로 좋은 해시 코드를 추측하려고 시도하지만 객체의 도메인 또는 값 범위를 알고 있기 때문에 여전히 더 나은 것을 제공 할 수 있습니다.

null재정의 할 때 obj 매개 변수를 확인하는 것을 잊지 마십시오 Equals(). 또한 유형을 비교하십시오.

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

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

    return fooItem.FooId == this.FooId;
}

그 이유는 다음 Equals과 비교할 때 false를 반환해야합니다 null. http://msdn.microsoft.com/en-us/library/bsc2ak47.aspx 참조

어때요?

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

성능이 문제가 아니라고 가정 :)

극복해야 할 두 가지 문제가 있습니다.

1. GetHashCode()객체의 필드를 변경할 수 있는 경우 적절한 정보를 제공 할 수 없습니다 . 또한 종종에 의존하는 컬렉션에서 개체를 사용하지 GetHashCode()않습니다. 따라서 구현 비용 GetHashCode()은 종종 가치가 없거나 불가능합니다.

2. 누군가 호출하는 컬렉션에 객체를 넣고 올바른 방식으로 동작 하지 않고 GetHashCode()재정의 한 경우 해당 사람이 문제를 추적하는 데 며칠이 걸릴 수 있습니다.Equals()GetHashCode()

따라서 기본적으로 그렇습니다.

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");
    }
}

프레임 워크는 동일한 두 개의 객체가 동일한 해시 코드를 가져야하기 때문입니다. equals 메소드를 대체하여 두 오브젝트의 특수 비교를 수행하고 메소드에서 두 오브젝트를 동일한 것으로 간주하는 경우 두 오브젝트의 해시 코드도 동일해야합니다. (사전 및 해시 테이블은이 원칙에 의존합니다).

위의 답변을 추가하면됩니다.

같음을 재정의하지 않으면 기본 동작은 객체의 참조가 비교되는 것입니다. 기본 코드는 일반적으로 참조의 메모리 주소를 기반으로합니다. Equals를 재정의했기 때문에 올바른 동작은 참조가 아닌 Equals에 구현 한 내용을 비교하는 것이므로 해시 코드에 대해서도 동일하게 수행해야합니다.

클래스의 클라이언트는 해시 코드가 equals 메소드와 유사한 논리를 가질 것으로 예상합니다. 예를 들어 IEqualityComparer를 사용하는 linq 메소드는 먼저 해시 코드를 비교하고 동일 할 경우에만 더 비싼 Equals () 메소드를 비교합니다 실행하려면 해시 코드를 구현하지 않으면 동일한 객체에 다른 해시 코드가있을 것입니다 (메모리 주소가 다르기 때문에) 동일하지 않은 것으로 잘못 결정됩니다 (Equals ()는 적중되지 않습니다).

또한 사전에서 객체를 사용하면 객체를 찾을 수없는 문제를 제외하고 (하나의 해시 코드로 삽입되었으므로 찾을 때 기본 해시 코드가 다를 수 있음) Equals () Marc Gravell이 그의 답변에서 설명하는 것처럼 호출되지 않을 것입니다. 동일한 키를 허용하지 않아야하는 사전 또는 해시 세트 개념의 위반을 소개합니다. 데이터 구조에서 두 키를 서로 다른 키로 사용하여 고유 한 키를 가지길 원하지는 않지만 해시 코드가 다르기 때문에 "같은"키가 다른 키로 삽입됩니다.

해시 코드는 Dictionary, Hashtable, HashSet 등과 같은 해시 기반 컬렉션에 사용됩니다.이 코드의 목적은 특정 객체를 특정 그룹 (버킷)에 넣어서 매우 빠르게 사전 정렬하는 것입니다. 이 사전 정렬은 코드가 포함 된 모든 객체가 아닌 하나의 버킷에서 객체를 검색해야하기 때문에 해시 수집에서 객체를 다시 검색해야 할 때이 객체를 찾는 데 크게 도움이됩니다. 해시 코드 (더 나은 고유성)를 더 잘 분배할수록 검색이 더 빨라집니다. 각 객체에 고유 한 해시 코드가있는 이상적인 상황에서 O (1) 연산을 찾는 것입니다. 대부분의 경우 O (1)에 접근합니다.

반드시 중요한 것은 아닙니다. 컬렉션의 크기와 성능 요구 사항 및 클래스가 성능 요구 사항을 모르는 라이브러리에서 사용되는지 여부에 따라 다릅니다. 필자는 컬렉션 크기가 그리 크지 않으며 완벽한 해시 코드를 생성하여 얻은 몇 마이크로 초 이상의 성능보다 시간이 더 중요하다는 것을 자주 알고 있습니다. 그래서 (컴파일러에 의한 성가신 경고를 없애기 위해) 나는 단순히 다음을 사용합니다.

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

(물론 #pragma를 사용하여 경고를 끌 수도 있지만이 방법을 선호합니다.)

물론 다른 사람들이 언급 한 모든 문제가 적용되는 것보다 성능 이 필요한 위치에있을 때 물론입니다. 가장 중요 -그렇지 않으면 해시 세트 또는 사전에서 항목을 검색 할 때 잘못된 결과를 얻을 수 있습니다. 해시 코드는 오브젝트의 수명 시간에 따라 달라져서는 안됩니다 (보다 정확하게는 해시 코드가 필요할 때마다, 예를 들어 예를 들어 Value가 public이므로 인스턴스의 수명 기간 동안 클래스 외부에서 클래스를 변경할 수 있으므로 해시 코드의 기초로 사용해서는 안됩니다.

   class A
   {
      public int Value;

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

반면에, Value를 변경할 수 없다면 다음을 사용해도됩니다 :

   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
      }
   }

Equals ()에 정의 된대로 두 객체가 동일한 경우 항상 동일한 해시 코드를 반환해야합니다. 다른 의견 중 일부는 이론적으로 객체가 HashSet 또는 Dictionary와 같은 해시 기반 컨테이너에서 절대 사용되지 않는 경우 필수적이지 않습니다. 그래도 항상이 규칙을 따르는 것이 좋습니다. 그 이유는 실제로 성능을 향상 시키거나 코드 의미를 더 나은 방식으로 전달하려는 의도로 누군가가 한 유형에서 다른 유형으로 콜렉션을 변경하기가 너무 쉽기 때문입니다.

예를 들어, 일부 객체를 List에 유지한다고 가정합니다. 언젠가 누군가는 예를 들어 더 나은 검색 특성 때문에 HashSet이 훨씬 더 나은 대안이라는 것을 실제로 알고 있습니다. 우리가 곤경에 처할 수있는 때입니다. List는 내부적으로 기본 평등 비교자를 사용합니다. 이는 HashSet이 GetHashCode ()를 사용하는 경우 Equals를 의미합니다. 둘이 다르게 동작하면 프로그램도 마찬가지입니다. 이러한 문제는 해결하기 가장 쉬운 방법이 아닙니다.

이 동작을 블로그 게시물의 다른 GetHashCode () 함정과 함께 요약하여 추가 예제와 설명을 찾을 수 있습니다.

현재 .NET 4.7재정의 바람직한 방법은 GetHashCode()다음과 같다. 이전 .NET 버전을 대상으로하는 경우 System.ValueTuple nuget 패키지를 포함하십시오 .

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

성능면에서이 메소드는 대부분의 복합 해시 코드 구현 보다 성능이 우수 합니다. ValueTuple는 A는 struct그래서 어떤 쓰레기가되지 않으며, 기본 알고리즘은 빨리이수록입니다.

원래 GetHashCode ()가 객체의 메모리 주소를 반환한다는 것을 이해하고 있으므로 두 개의 다른 객체를 비교하려면이를 재정의해야합니다.

편집 : 잘못되었습니다. 원래 GetHashCode () 메소드는 2 값의 동등성을 보장 할 수 없습니다. 동일한 객체는 동일한 해시 코드를 반환하지만

아래의 리플렉션 사용은 공용 속성을 고려할 때 더 나은 옵션 인 것처럼 보입니다. 이와 함께 속성 추가 / 제거에 대해 걱정할 필요가 없습니다 (일반적인 시나리오는 아니지만). 이 또한 성능이 더 우수하다는 것을 알았습니다. (대각선 스톱워치를 사용한 시간 비교).

    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;  
    }