为什么在 java.util.Collection 上有一个方法 iterator()答案

【问题标题】：Why is there a method iterator() on java.util.Collection为什么在 java.util.Collection 上有一个方法 iterator()
【发布时间】：2011-01-06 09:19:59
【问题描述】：

当接口 java.util.Collection 已经扩展了定义了这个方法的 java.util.Iterable 时，为什么还要在接口 java.util.Collection 上定义方法 iterator()。

我正在考虑某种向后兼容性，或者有机会在集合级别的方法上编写一些 JavaDoc。

还有其他想法吗？

【问题讨论】：

不错，我支持向后可比性，但不确定
有一个类似的 SO 问题（我的 google fu 缺少）处理 Set 与 Collection 具有相同的方法声明，并且它们是在同一版本（1.2）中引入的。

标签： java iterator collections iterable

【解决方案1】：

我对此进行了更多调查，发现 equals() 和 hashcode() 方法也被覆盖了。

显然，这样做的唯一原因可能是添加 javadoc - 也许这就是 iterator() 也被覆盖的原因。

【讨论】：

【解决方案2】：

可迭代是在 1.5 中引入的。由于它是 1.5 之前的 Collection 的一部分，因此他们可能只是没有将其删除。正如另一位贡献者所指出的，它确实有更好的 JavaDoc。

【讨论】：

【解决方案3】：

我怀疑这只是为了避免从文档的角度删除方法。尽管 javadoc 很好，但很难注意到/欣赏从一个接口移动到超级接口的方法。

请注意，Closeable 也是如此，同样在 1.5 中引入。

据我所知，从 Collection 类中删除该方法不会出现二进制兼容性问题。

【讨论】：

确实，也不存在任何源兼容性问题。（Collection 接口，顺便说一句）。我相信您需要一种元语言工具（例如反射）来在运行时区分差异。

【解决方案4】：

向后兼容性。 Iterable 直到 1.5 才通过 for(Object o : iterable) 构造引入。以前，所有集合都必须提供一种迭代它们的方法。

【讨论】：

iterator() 不只是为了向后兼容而存在；直接拥有 Iterator 的句柄通常很有用。
@Adamski，Dan 在问，当 Collection 扩展 Iterable 时，为什么要在 Collection 和 Iterable 上声明该方法。您的观点似乎是在解决“为什么有一个方法 .iterator()，句号？”没人问。
是的 - 对不起；我意识到了这一点并破坏了我的答案！
我也相信foreach循环（Object o:Iterable）被编译器重写为使用迭代器。没有迭代器意味着没有foreach:)
这个答案实际上是不正确的。 Collection 中的声明对于源代码或二进制兼容性都不是必需的。