3
Dictionary<T,U> 컬렉션에서 키로 사용하려는 클래스 T이 있다고 가정합니다.참조 유형의 값을 사전 키로 사용하려면 어떻게해야합니까?
T 참조에서 T이라는 값을 기반으로 키를 사용해야하는 이유는 무엇입니까?
나는 단지 GetHashCode() 일뿐입니다.
A
답변
5
GetHashCode() 및 Equals()를 구현해야합니다.
사전 커버 아래 해시 테이블, 그래서 당신은이 부분을 읽어보십시오 : Pitfalls Of Equals/GetHashCode – How Does A Hash Table Work?
2
당신은 Equals(object obj)를 오버라이드 (override) 할 필요가있다. Equals을 수정할 때 항상 GetHashCode을 구현해야합니다. MSDN에서 article을 읽으십시오.
3
당신이 사전 생성자에서 어떤 IEqualityComparer<T>를 통과하지 못한 경우로 MSDN에 의해 정의된다 EqualityComparer<T>.Default 사용합니다 : 타입 T가 T 중합니다 (System.IEquatable를 구현하는지 여부를
기본 속성 검사를) 인터페이스가있는 경우 EqualityComparer (Of T)를 반환합니다. 은 해당 구현을 사용합니다. 당신이 그것을 구현하는 경우 그렇지 않으면, 는 T.에 의해 제공 Object.Equals 및 Object.GetHashCode의 오버라이드 (override)를 사용 (T의)는 EqualityComparer 반환
그래서 내 선택이 될 것입니다 IEquatable<T>를 구현하는 (그것도 의미가 있습니다 그래도 Equals 및 GetHashCode을 무시하십시오.
3
어느는 Equals 및 GetHashCode또는이지도에 대한 일치하는 평등의 오른쪽 양식을 가지고 적절한 IEqualityComparer<T>를 만들 구현합니다.
나는 다소 IEqualityComparer<T> 경로를 좋아한다 : 많은 경우에 평등의 명백한 형태는 하나도 없다. 상황에 따라 객체를 다른 방식으로 동일하게 취급하고 싶다. 이 경우 사용자 정의 동등 비교자가 필요한 것입니다. 물론 이 자연 평등 연산 인이면 형식 자체에 IEquatable<T>을 구현하는 것이 좋습니다. 가능하면 가능합니다. (IEqualityComparer<T>의 또 다른 이점은 제어 할 수없는 유형에 대해 구현할 수 있다는 것입니다.
파생 형식이 Object.Equals를 재정의하면 나쁜 일이 발생할 것이므로 상속 가능한 유형의 IEquatable 구현이 권장되지 않습니다. Object) 및 Object.GetHashCode (Object) 및 IEquatable의 구현은 이러한 재정의를 호출하지 않습니다. 오버라이드를 호출하기 위해 Object로 형변환하면 일반 인터페이스를 사용하여 얻을 수있는 이점을 모두 상실하게되므로 실제로이를 구현할 필요가 없습니다. –
supercat