忽略equals/hashCode中某些字段的潛在缺陷？

Question

如果只是一些對象的字段表示實際狀態，我想這可能重寫equals和hashCode時忽略...

我得到這個一種不安的感覺，雖然，想問問，

1. 這是常見的做法嗎？
2. 這種方法有沒有什麼潛在的缺陷？
3. 當涉及到忽略equals/hashCode中的某些字段時，是否有任何文檔或準則？

---

在我的特定情況下，我在探索一個問題的狀態空間。我想保留一組訪問狀態，但我也考慮包括導致該狀態的路徑。顯然，兩個國家是平等的，儘管它們是通過不同的途徑找到的。

Answer 1

這是基於您如何考慮給定對象的唯一性。如果它有一個主鍵（唯一鍵），那麼單獨使用該屬性就足夠了。

如果您認爲唯一性是10個不同屬性的組合，那麼請在等於中使用全部10個屬性。

然後只使用您在equals中使用的屬性來生成哈希碼，因爲相同的對象應該生成相同的哈希碼。

爲equals和hashcode選擇屬性是您如何定義給定對象的唯一性。

• 這是常見的做法嗎？是

• 這種方法有沒有什麼潛在的缺陷？否

• 是否有任何文檔或準則，當涉及到忽略equals/hashCode中的一些字段？

  「類Object的equals方法實現了最有區別的 對象上的可能等價關係;」

這是從對象類的Javadoc。但作爲班級的作者，你知道獨特性是如何定義的。

Answer 2

最終，「等於」意味着你想要它的意思。有一個限制，即「相等」的值必須返回相同的哈希碼，當然，如果兩個相同的地址「等於」必須返回true。但是，例如，你可以有一個比較兩個網頁內容的「平等」（忽略隨機數的可重複性問題），即使網址不同，如果網頁內容與某些內容匹配辦法。

Answer 3

我所看到的用於覆蓋Object上方法的最佳文檔/指南是Josh Bloch的Effective Java。它有關於「所有對象通用的方法」的一章，其中包括有關「在覆蓋等於時服從一般合同」和「當您覆蓋等於時總是覆蓋hashCode」的章節。它詳細描述了重寫這兩種方法時應考慮的事項。我不會直接給出答案;這本書絕對值得每個Java開發者的成本。