为什么 Collections 类中的 sort 等方法不在 List 接口中？

Question

Class Collections 有一些静态方法作为操作 List 等集合的实用程序。例如排序方法（Collections.sort(list)）。我不明白为什么 Java 规范创建了另一个类来承载排序方法（以及所有其他方法，如 binarySearch）而不是 List 接口和具体的子类，如 ArrayList 和 LinkedList 实现这些方法。

更新

当我进行全球研究并阅读这篇文章的答案时，我不得不说（鸟瞰图）： 有人（我提到@dan，@WJS，@cdalxndr）在这篇文章中说，以sort方法为例，因为ArrayList和LinkedList的排序可以用相同的方式完成，所以我们可以实现一次写入。所以（我说）我们可以将代码放在 List 接口中，但是在 Java 7 之前，我们不能将任何实现放在接口的主体中，并且有一次编写它的唯一方法是在实用程序类中实现。但是由于 Java 8 接口具有“默认”方法的特性。 Java 团队利用这个特性在接口级别实现了排序方法，并且该方法可以被 ArrayList 和 LinkedList 使用（默认情况下，如果类不覆盖它）

Answer 1

在 Java 8 之前，接口不能有 default 或 static 方法，因此，添加到接口的每个方法都需要由实现该接口的所有类实现。即使您在支持类中提供了有用的实现，实现类也至少需要一个委托方法。

因此，除非您想强制所有实现从提供这些方法的某个抽象基类继承，否则您必须小心添加到接口中的内容。

即使使用default 方法，您也必须小心，避免使用太多方法污染实现类的名称空间。这也可能是 Java 8 中并非所有操作都被改进为 default 方法的原因：

虽然将default 方法添加到接口的侵入性较小，因为它不需要在现有的实现类中实现它，但它仍然可能导致与实现类的具体方法发生冲突' t 实现之前版本的接口方法。

想象一下，在 Java 8 时代之前的自定义 List 实现提供了一个有用的 void sort(Comparator c) 实例方法，只是委托给 Collections.sort(this, c);。这在 Java 8 之前有效，没有提高性能，但允许编写 list.sort(c);。如今，此方法会无意中覆盖具有相同名称和类型的 default 方法，Collections.sort 将委托给该方法，从而产生无限循环（或者更确切地说，递归）。

由于直接的好处，sort 方法已添加到List 接口中。与Collections 实用程序类中的static 方法不同，default 方法可以被覆盖。这已针对最常用的列表类型ArrayList、Vector 和Array.asList(…) 返回的实现完成。由于所有这些实现都由数组支持，因此覆盖方法可以直接使用支持数组委托给Arrays.sort，而default 实现将使用列表内容的临时副本。

还值得注意的是，Collections 中的那些方法似乎最初是基于这些算法适用于所有类型的实现的假设，但事实并非如此。引入 Collection API 之后的两个版本，引入了 RandomAccess 标记接口，以区分两个根本不同的列表实现类别，因此静态方法可以分支到基于它的两种替代算法。

每当我们必须基于我们正在操作的类进行分支时，我们可以质疑抽象并说我们可能会更好地使用类型本身的可覆盖方法，但如上所述，存在历史原因设计，仍然有理由要小心向接口添加方法。

Answer 2

排序是一种算法，List 是一个容器。

开发人员希望将列表算法（排序、二进制搜索等）与容器逻辑（添加、删除等）分开，因此他们将算法放入实用程序类 Collections。

Answer 3

从 Java 8 开始有某种选项，只需要您定义（或使用预定义的比较器）。

下面的虚拟示例：

    List<Integer> list = new ArrayList();
    list.addAll(List.of(1,5,4,3,6,8,9,2));

    list.sort(Comparator.naturalOrder());

但显然，作为用户，它与在 Collections util 中的方式不同（尽管我确实相信 Collections 实现也使用此类比较器或类似的东西进行环绕）。

Answer 4

因为没有必要。以下所有扩展Collection

BeanContext, BeanContextServices, BlockingDeque<E>, BlockingQueue<E>,<br>
Deque<E>, EventSet, List<E>, NavigableSet<E>, Queue<E>, Set<E>,<br>
SortedSet<E>, TransferQueue<E>

所以您提倡的是每个接口都为Collections 中的每个方法提供完全相同的实现，或者可能是一种方便的方法。恕我直言，那将是一种代码膨胀的形式。在前一种情况下，如果发现改进，则需要更改多个实现。

我知道他们在List 接口中添加了sort，可能是因为这是一个常见的要求。但我从来没有遇到过使用Collections.sort 进行排序的问题。可能还有其他我不知道的原因。

但我倾向于认为Collections 与Math 类非常相似。 Double 和 Integer 没有重复的数学函数。与Math 类似，Collections 是一个utility，它提供了可供相关类使用的各种静态方法。当然，Math 类不在 Double 或 Integer 等 hierarchy 中，但它的用途非常相似。

Answer 5

Collections Framework（主要是在Sun Microsystems 工作时的Josh Bloch）的设计者与 Java API 的许多其他部分一样，着眼于该语言的寿命。 Java 将 API 的维持和演变的概念直接结合到文档支持的语法中，并带有 @deprecated 标签。 具体来说，他们预计可能会在多年后开发出更多的排序和搜索算法，然后才能发现更多的“容器”操作以添加到Collection 和List 接口中。

他们非常清楚界面的更改会要求开发团队处理升级要求。升级要求减缓了 Sun Microsystems 希望团队能够轻松接受的修复和改进的采用。将用于排序和搜索的新方法合并到界面中将大大阻碍该目标；给选择升级到 Java 语言最新版本的团队带来了不必要的负担。相反，他们明智地选择将这些实用程序方法分流到静态实用程序类。

与 Java 8 的 List.sort(..) 一样，我只能猜测 Oracle 感受到了行业和其他语言的压力，将这些常见操作直接纳入其集合本身。但是，将这些实用程序与集合分开可以最大限度地减少它们对直接实现其接口的人的采用要求。