Comparator/able 中的 equals() vs compareTo()（理论）答案

【问题标题】：equals() vs compareTo() in Comparator/able (Theoretical)Comparator/able 中的 equals() vs compareTo()（理论）
【发布时间】：2012-05-31 12:29:34
【问题描述】：

我不懂 Javadoc：

The natural ordering for a class C is said to be consistent with equals if and only if
  (e1.compareTo((Object)e2) == 0) has the same boolean value as e1.equals((Object)e2) for
  every e1 and e2 of class C.

为什么会这样？

我知道 e1.equals(e2)=true 应该总是暗示 e1.compareTo(e2)==0，但我不明白为什么相反的情况应该成立。比较不是平等！ 2 个相等的对象应该与零进行比较，但如果排序标准与它们的情况不相关，则 2 个不同的对象应该能够比较为 0。我的意思是，不同的对象相等是不正确的，但不同的对象具有 0 比较为什么不呢？

编辑：后来它说强烈推荐一致性，因为一些兼容性问题，因此问题

【问题讨论】：

我不明白这个问题，这是compareTo()和equals()之间“一致性”的定义，它没有说你应该或不应该做什么，只是给出一个定义。
好的，但后来它说它是推荐的，我不明白为什么。即便如此，我也无法理解为什么与零相比不相等的对象在哲学观点上不一致

标签： java collections equals comparator comparable

【解决方案1】：

Javadoc 并没有说错误进行与 equals 不一致的比较。它只是定义与等于一致的比较的术语。

当您做出选择时，通常最好进行与 equals 一致的比较，例如给定 A 和 B，A 小于、等于或大于 B - 但事实并非如此必须以这种方式工作。

重要的是，您记录这一点 - 调用者可能会对意外与 equals 不一致的顺序感到非常困惑。

【讨论】：

但是为什么认为 compareTo==0 应该意味着完全相等？我会说它们在排序时没有不同的优先级
让两个对象评估为相等但具有不同的排序优先级是奇怪（但不一定是错误的）。奇怪（但同样，不一定是错误的）拥有不同的可排序对象并且无法确定排序优先级。

【解决方案2】：

他们只是在谈论自然排序。您可能需要不同类型的订单

【讨论】：

【解决方案3】：

java 文档讨论了自然排序。您可以随意比较它们。但如果它是关于自然排序，那么你不认为它必须是双向的吗？

即使在一天 50 个月之后也不会到达我们可以看到整数的自然顺序被颠倒的地方；）

【讨论】：

【解决方案4】：

以BigDecimal 类为例，在该类中equals 和compareTo 的方法彼此不一致：

equals 文档说：

公共布尔等于（对象 x）

将此 BigDecimal 与指定的 Object 进行比较是否相等。与 compareTo 不同，此方法认为两个 BigDecimal 对象相等仅当它们在值和规模上相等时（因此 2.0 不等于用此方法比较时为 2.00）。

【讨论】：

正确，完美的例子。但是为什么应该被认为是“不一致的”？ 2.0 不完全是 2.00，但比较时它们应该处于不明确的排序位置