複数の型のインスタンスの内部ハッシュコードを計算する必要があります (一部の型は互いに派生しています)。ここでは 2 つの側面が動的であり、独立して変化する可能性があります。ハッシュを要求するクライアントだけが、どのハッシュ アルゴリズムが使用され、どのプロパティが含まれるかを知っています。
- ハッシュ計算に使用される実際のアルゴリズムは変更される可能性があります。
- ハッシュ計算で考慮すべき各タイプのメンバーは変更される可能性があります。
これらの要件に合わせて型をどのように設計しますか?
複数の型のインスタンスの内部ハッシュコードを計算する必要があります (一部の型は互いに派生しています)。ここでは 2 つの側面が動的であり、独立して変化する可能性があります。ハッシュを要求するクライアントだけが、どのハッシュ アルゴリズムが使用され、どのプロパティが含まれるかを知っています。
これらの要件に合わせて型をどのように設計しますか?
まず、1つのメソッドを使用して、すべての「ハッシュ可能な」オブジェクトに同じインターフェイスを実装するように要求しますgetHash()
。
次に、ハッシュストラテジーをインスタンス化するAbstractFactoryを導入します。
例(Java 1.6):
public class Foo implements Hashable {
private String field;
@Override
public String getHash() {
HashFactory.INSTANCE.getMD5Strategy().hash(this.field);
}
}
オブジェクト内での意思決定の適切なカプセル化、および戦略とオブジェクトの効果的な分離。
Eric Lippert による GetHashCode() のガイドラインを次に示します。
http://ericlippert.com/2011/02/28/guidelines-and-rules-for-gethashcode/
抜粋:
ルール: ハッシュ コードが安定していることに依存するデータ構造にオブジェクトが含まれている間、GetHashCode によって返される整数は決して変更してはなりません。
危険ではありますが、オブジェクトのフィールドが変化するにつれてハッシュ コード値が変化する可能性があるオブジェクトを作成することは許容されます。そのようなオブジェクトがあり、それをハッシュテーブルに入れる場合、オブジェクトを変更するコードとハッシュテーブルを維持するコードには、オブジェクトが存在している間に変更されないことを保証する合意されたプロトコルが必要です。ハッシュテーブル。そのプロトコルがどのように見えるかはあなた次第です。
つまり、ハッシュ コードを生成するためのアルゴリズムが変更される可能性がある場合は、オブジェクトがコレクション内にある間はアルゴリズムが変更されないようにする必要があります。