对于Collections 中所有将List 作为第一个参数的方法，为什么这些方法不只是List 接口的一部分？
我的直觉是：给定一个 List 对象，该对象本身应该“知道”如何对其自身执行操作，例如 rotate()、shuffle() 或 reverse()。但是，作为一名 Java 程序员，我必须检查 List 接口中的方法以及 Collections 类中“那边”的静态方法，以确保我使用的是规范的解决方案。
为什么有些方法作为静态独立方法放置在 Collections 类中，而不是添加到 List 接口中（并且可能因此由某些现有或可能的基类实现）？
我试图更好地理解 Java 集合框架背后的设计决策。
我忽略了一些引人注目的面向对象设计原则吗？或者这种区分仅仅是出于某种实际的性能原因？
【问题讨论】：
标签： java collections
关键在于，如果给定合适的原始操作（删除、设置等），则可以实现一次更高级的操作（排序、随机播放、二分搜索），而不是由每个单独的操作来实现列表实现。
实际上，java.util.Collections 就像 .NET 的 Enumerable 类 - 充满了可用于任何集合的通用方法，因此它们可以共享单个实现并避免重复。
【讨论】：
Java 的作者现在可能会做非常不同的事情，因为他们对 API 的多年使用有后见之明。也就是说，C# IList 接口与 Java 非常相似，C# 的作者确实有这种观点。
【讨论】：
这当然是某种程度的判断。我认为要考虑的主要权衡是：当您向接口添加方法时，该接口的每个实现者都必须编写代码来实现它。
如果该方法的语义使得接口的不同实现会以非常不同的方式最好地实现这些语义，那么最好将它放在接口中。 （当然，如果语义根本无法用接口中的其他方法来定义，那么它必须是接口中自己的方法。）
另一方面，如果语义可以根据接口中的其他方法来定义，并且接口的实现者会倾向于一遍又一遍地编写相同的代码，那么最好使将接口实例作为参数的实用方法。
【讨论】：
它们是实用方法，而不是核心列表功能。如果您添加了所有可以对 List 执行的操作，List 界面就会变得臃肿。而且 Collections 中的操作不需要了解 List 的内部结构，它们在公共接口上操作，因此可以愉快地存在于外部类中。
【讨论】：
这里有两种解释：
历史：集合类是在 List 接口之后创建的。设计人员选择保留现有接口的向后兼容性。否则很多开发人员将不得不更改他们的代码。
逻辑：您所谈论的方法不需要有关 List 实现的内部知识，并且可以在任何实现它的集合上实现。
【讨论】：