根據等號和哈希碼實現compareTo

與使用equals和hashcode相比，它是一個壞主意（可能會有後果我忽略）嗎？我不關心我只需要排序的元素的排序是確定性的。這當然假設我的equals和hashcode是正確的。根據等號和哈希碼實現compareTo

這裏是我的compareTo是什麼樣子

@Override 
public int compareTo(DividendEvent other) { 
    final int BEFORE = -1; 
    final int EQUAL = 0; 
    final int AFTER = 1; 

    if(other == null){ 
     return BEFORE; 
    } 
    else if (this.equals(other)){ 
     return EQUAL; 
    } 
    else if (this.hashCode()>other.hashCode()){ 
     return AFTER; 
    } 
    else{ 
     return BEFORE; 
    } 
}

來源

2015-12-17 thermite

您是否實現了'hashCode'方法來考慮某種排序？ –

真的沒有比hashcode更好的屬性來比較嗎？ – Kayaman

糟糕的想法 - 'equals'很好，但'hashCode'不能保證也不會是唯一的，只是'bucketing'。即使你實現它是唯一的，它不會再作爲一個好的hashCode。 – Kenney

有什麼事情，以避免「奇怪的事情」是符合the contract of compareTo，即：

sgn(x.compareTo(y)) == -sgn(y.compareTo(x))
(x.compareTo(y)>0 && y.compareTo(z)>0)意味着x.compareTo(z)>0
x.compareTo(y)==0暗示sgn(x.compareTo(z)) == sgn(y.compareTo(z))適用於所有z

您的實現不勾選不相等但具有相同散列碼的對象的第一個框。

你可以修改它想：

else if (this.equals(other) || this.hashCode() == other.hashCode()){

剔三盒。你的實現然後會變得與平等不一致，但除此之外它看起來很好。

這假定您hashCode是給定對象不變。

來源

2015-12-17 19:02:37 assylias

「與equals不一致」意味着兩個不同的（不相等的）對象可能是相等的，這意味着它們保留了sort（）中的原始順序。在這種情況下，確定性排序的目標只有在原始順序是確定性的情況下才是真實的，如果情況如此，則不需要所有這些，因此：仍然不確定。解決方案不可行。 – Andreas

似乎合理。我將承擔碰撞的風險，因爲發生這種情況的結果是在審計表中有空的入場機會爲50％（ish）...... – thermite

有時框架需要覆蓋.equals（）才能工作，（我在jsf + ejb中遇到過這種情況），並且該類型的實現需要根據對象ID進行相等性檢查。當你以這種方式實現compareTo，並且「比較」對象的邏輯與此不同時，這會導致混淆。

如果這些類是您的域對象，你是不是在其它層使用它們，它可能確定。我只是認爲.equals方法以技術方式（例如相同的數據庫ID）指示相等性，以及您以自己的業務邏輯方式實現的.identical（）等其他方法。

來源

2015-12-17 19:28:52 Reek

根據等號和哈希碼實現compareTo

回答

相關問題