为什么 java 坚持开发人员在处理排序集合时添加比较机制而不是使用默认比较机制？

Question

假设我们有一个 class Foo 喜欢

class Foo {
    private int attr1;
    private String attr2;
    // getters and setters.
    // hashCode and equals not overrided.
}

因此，在将 Foo 的引用添加到 Set 或 Map（作为键）时，将根据其地址位置识别重复项。现在，如果我基于 attr2 覆盖 hashCode 和 equals，将根据 attr2 的 value 识别重复项。这就是重复过滤在 Java 中的工作方式 - 查找任何用户定义的机制，如果存在则使用该机制，否则使用默认机制。

如果我们尝试将 Foo 的引用添加到像 TreeSet、TreeMap 这样的排序集合中，它将抛出 ClassCastException 表示没有比较机制。所以我们可以使它成为 Comparable 或 Comparator 类型，并且可以定义一个比较机制。

所以我的问题是在查找重复项时，如果用户没有定义任何机制 Java 将查找默认机制，但在排序或比较时它坚持要求用户定义机制。为什么它不采用默认机制，例如根据 hashcode 比较引用？是否因为任何 OOP 概念或 Java 中的任何概念如果进行默认比较都可能被违反？

Answer 1

TL;DR 给我一个合理的方法来定义不透明对象之间的总排序。

在没有任何其他信息的情况下，只有在物理上相同时，对象才相同。这是默认 equals 和 hashCode 所做的。

说一个对象比另一个对象 "bigger" 是不明智的，而且确实没有意义，因为它的内存位置摘要更大。

对于你提出的机制来说更糟糕的是，在现代 Java 中，hashCode 是一个内存位置的古老格言是 actually incorrect。 Object 在构造时被分配了一个随机数，用作 hashCode.

所以你真的是在求婚：

"缺少任何有关订购对象的信息，我们将完全随机订购"

我想不出这种默认行为是什么情况：

预计
有用

为什么 java 坚持开发人员在处理排序集合时添加比较机制而不是使用默认比较机制？

Why java insist developers to add a comparison mechanism rather than using a default comparison mechanism while working on sorted collection?

java

comparison

default

TL;DR 给我一个合理的方法来定义不透明对象之间的总排序。