为什么Collections类包含独立(静态)方法,而不是将它们添加到List接口?

关键是,给定适当的原语操作(remove、set等),可以实现一系列更高级的操作(sort、shuffle、binary search) 一旦

实际上,java.util.Collections类似于.NET的可枚举类—充满了可用于任何集合的通用方法,因此它们可以共享单个实现并避免重复。

列表接口方法背后的Rational

1. List接口是Java运行时的一个非常核心的部分,在推出自己的List实现时,要完全实现所有成员已经有点麻烦了。因此,添加与列表定义不直接相关的额外方法有点无关。如果您在列表实现中需要这些方法,为什么不对接口进行子类化,然后需要它们呢?
2. 如果您打算在版本1.3中添加功能,并通过添加新的实用工具方法来添加List接口,那么您将打破该接口的所有以前的实现者。
3. 从域驱动的设计角度来看,集合中的实用程序方法不是列表的常规域的一部分。
4. 关于OO设计原则,我认为区分应用程序OO设计和语言运行时OO设计是很重要的。

每一个 该接口的实现者必须编写代码来实现它。

如果该方法的语义使得接口的不同实现能够以非常不同的方式最好地实现这些语义,那么最好将其放在接口中(当然,如果语义不能用接口中的其他方法来定义,那么 必须 在接口中有自己的方法。)

另一方面,如果语义可以用接口中的其他方法来定义,而接口的实现者只会一遍又一遍地编写相同的代码,那么最好创建一个实用方法,将接口的实例作为参数。

它们是实用方法,而不是核心列表功能。如果在列表中添加所有可能的操作,列表界面就会变得臃肿。集合中的操作不需要知道列表的内部结构,它们在公共接口上操作,因此可以愉快地生活在外部类中。

这里有两种解释:

1. 历史:集合类是在列表接口之后创建的。设计者选择保留现有接口的向后兼容性。否则很多开发人员将不得不更改他们的代码。

2. 逻辑:您所讨论的方法不需要关于列表实现的内部知识,并且可以在实现它的任何集合上实现。