1

여러 유형의 인스턴스 (일부 유형은 서로 파생 됨)의 내부 해시 코드를 계산해야한다는 요구 사항이 있습니다. 여기에 동적 인 두 가지 측면이 있으며 은 각각입니다. 해시를 요청하는 클라이언트 만 사용되는 해시 알고리즘과 포함될 속성을 알고 있습니다.동적 GetHash 함수에 대한 클래스 디자인

  1. 해시 계산에 이 사용 된 실제 알고리즘이 변경 될 수 있습니다.
  2. 해시 계산에 고려해야 할 각 유형의 멤버를 변경해야합니다.

이러한 요구 사항을 어떻게 해결할 수 있습니까?

답변

0

다음은 Eric Lippert의 GetHashCode()에 대한 몇 가지 지침입니다.

http://ericlippert.com/2011/02/28/guidelines-and-rules-for-gethashcode/

발췌 :
규칙 : 개체가 안정

그것은 허용된다는하지만 나머지 해시 코드에 따라 데이터 구조에 포함되는 동안 GetHashCode에 의해 반환되는 정수 변경하지 말아야합니다 위험한, 개체의 필드가 변함에 따라 해시 코드 값이 변이 될 수있는 개체를 만드는 것입니다. 그러한 객체를 가지고 해시 테이블에 넣으면 해시 테이블을 유지 관리하는 객체와 코드를 변경하는 코드에 객체가 변형되어 있지 않은지 확인하는 합의 된 프로토콜이 필요합니다. 해시 테이블 그 프로토콜은 당신에게 달려 있습니다.

요약하면 해시 코드 생성 알고리즘이 변경 될 수 있다면 개체가 컬렉션에있는 동안 변경되지 않도록해야합니다.

+0

내 질문의 초점은 GetHashCode가 아닙니다 (이것은 단지 예제 일뿐입니다). 내가 책임을 져야 할 때 클래스 디자인 옹호에 더 많은 변화가있을 수 있습니다. 내 질문을 수정하고 이것을 강조하기 위해 .NET 태그를 제거했습니다. – bitbonk

0

먼저 "해시 가능"객체가 모두 동일한 인터페이스를 구현해야하며 한 가지 방법 : getHash()이 있어야합니다.

두 번째로 Abstract Factory 인스턴스화 해시 Strategies을 소개합니다.

예 (자바 1.6) :

public class Foo implements Hashable { 
    private String field; 
    @Override 
    public String getHash() { 
    HashFactory.INSTANCE.getMD5Strategy().hash(this.field); 
    } 
} 

하여 객체의 내부 의사 결정의 적절한 캡슐화 및 전략과 객체의 효과적인 디커플링.

+0

해시에 필드가 포함되도록 결정을 어떻게 캡슐화합니까? 객체는 알 수 없으며 해시 전략은 알 수 없습니다. 실제로 해시를 얻으려는 클라이언트 만 해시가 무엇인지 (즉, 사용할 알고리즘과 포함 할 필드를 알고 있습니다.) 나는 나의 질문을 개정하고 명확하게했다. – bitbonk

+0

해시가 클라이언트에 의해 요청 될 때 해시 계산의 두 가지 독립적 인 측면을 즉시 주입해야한다고 생각합니다. – bitbonk