Java集合的包装结构（java.util）-为什么Iterable位于java.lang中？

如下图所示，除了interface之外Iterable，所有其余构造（interface / class / abstract class）都位于同一包中java.util

在此处输入图片说明

为什么Iterable坐在java.lang包中？

注意：目的是要了解Java编程的包装方面。

java api packages collections

— 过度交换
source

不知道为什么将其标记为java8，此处询问的所有API都更旧。可迭代是在Java版本1.5，集合框架在1.2推出

— 蚊蚋

Answers:

正如其javadoc中所解释的那样，的目的Iterable是支持特定的语言语法：

实现此接口允许对象成为“ foreach”语句的目标

因此，它属于lang软件包，

提供对Java编程语言的设计至关重要的类。

图中的其他类属于JCF，因此在util包中

包含集合框架...

— gna
source

+1。我认为，虽然，Iterator最好应该也可以java.lang，因为Iterable是。当然，它必须是java.util出于向后兼容的原因而存在的（早在“ foreach”构造使它在语言本身中起作用之前，它已在JDK中引入）。

— ruakh 2015年

@ruakh迭代器很方便，但可能被认为过于具体（方法选择和命名），无法使用“基本”软件包。想想它的前身Enumeration最终并不像最初想像的那样方便，但谨慎的做法是它没有使用lang包

— gnat 2015年

我的意思不是说方便，而是现在取决于它的语言。（请注意，除了Iterableon 的依赖项外Iterator ，该java.lang软件包通常不依赖于。中的类java.util。）

— ruakh 2015年

@ruakh我明白了。很好，谢谢。我能理解为什么API设计人员希望Iterable公开“执行迭代的对象”，但是他们选择执行此操作的方式并不雅致

— t

因为很多事情都实现了Iterable接口或将其扩展为子接口。

实现类是：

这是一个巨大的清单。它涉及各种包装。

此外，您还希望最小化循环软件包的依赖关系。如果包A中的类依赖于包B中的类（依赖于包A中的类），则您具有循环依赖关系。它们的存在并不总是坏的-但是它们会导致其他循环依赖关系，这可能是一件坏事。它本身并不坏，但是它是一种设计气味，表明两个类或包装之间的耦合太紧密。这是积累技术债务的开始。

解决方案是说“是的，在整个java和javax结构中，Iterable接口是依赖于各种类和程序包的。它应该是语言库中最基础的-Java .lang。”

这就是您会找到它的地方。