1

我有要求計算幾種類型的實例(某些類型是相互派生的)的內部哈希碼。這裏有兩個方面是動態的,可以獨立變化。只有請求哈希的客戶端知道要使用什麼樣的哈希算法以及要包含哪些屬性。用於動態GetHash函數的類設計

  1. 使用 作爲散列函數的實際算法可以更改。
  2. 散列計算應考慮哪些類型的成員可以更改。

你會如何根據這些要求設計你的類型?

回答

0

下面是Eric Lippert的GetHashCode()的一些指導原則。

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

的摘錄:
規則:在對象被包含在數據結構依賴於保持穩定

這是允許的,雖然哈希碼通過的GetHashCode返回的整數決不能改變危險的是,使對象的哈希碼值可以隨着對象的字段變化而變化。如果你有這樣一個對象,並把它放在一個散列表中,那麼修改對象的代碼和維護散列表的代碼都需要有一些協議一致的協議,以確保對象在處於哈希表。這個協議看起來是由你決定的。

簡而言之,如果生成哈希碼的算法可以改變,那麼你需要確保它在對象不在集合中時不會改變。

+0

我的問題的焦點不在GetHashCode上(這只是一個實例)。當我需要承擔責任時,這更多的是在課堂設計上。我修改了我的問題,並刪除了.NET標籤以強調這一點。 – bitbonk 2011-03-24 18:53:33

0

首先,要求所有「可哈希」對象實現相同的接口,使用一種方法:getHash()

二,介紹一個Abstract Factory實例化散列Strategies

例(Java 1.6的)決策的對象中的

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

適當封裝,戰略和目標的有效分離。

+0

如何封裝決策制定字段將包含在散列中。該對象無法知道並且散列策略無法知道。只有想要實際獲得散列的客戶端知道散列的用途(即使用什麼算法以及要包含哪些字段)。我更新並澄清了我的問題。 – bitbonk 2011-03-25 15:51:50

+0

我認爲散列計算的兩個獨立方面必須在客戶端請求散列時即時注入。 – bitbonk 2011-03-25 15:59:40