在java语言中，什么时候应该接受Iterable<T>和Collection<T>的参数？
在Java中使用Iterable与使用Collection的注意事项是什么？
例如，考虑实现一个主要涉及包含Foo集合和一些相关元数据的类型。此类型的构造函数允许一次性初始化对象列表。(元数据可以稍后设置。)此构造函数应接受什么类型？Iterable<Foo>还是Collection<Foo>
这一决定的考虑因素是什么？
遵循诸如ArrayList (可以从任何Collection初始化，但不能从Iterable初始化)之类的库类型提出的模式将导致我使用Collection<Foo>。
但是，既然Iterable<Foo>足以满足初始化需求，为什么不接受它呢？为什么要从消费者那里要求比严格必要的功能(Iterable)更高级别的功能(Collection)？
回答 9
Stack Overflow用户
发布于 2009-07-21 15:16:57
许多集合类型在Iterable (它在1.5中才引入)之前就已经存在了-几乎没有理由添加一个构造函数来接受Iterable<T>和Collection，但是更改现有的构造函数将是一个破坏性的变化。
就我个人而言，如果Iterable<T>允许你做任何你想做的事情，我会使用它。对于调用者来说，它更加灵活，特别是它允许您使用Google Java Collections (毫无疑问还有类似的库)进行相对简单的过滤/投影等操作。
Stack Overflow用户
发布于 2009-07-21 15:23:04
Iterable生成Iterator对象。根据定义，Iterator对象是迭代的。注意，Iterator接口并不保证在hasNext()返回false之前next()可以被调用多少次。Iterator可能会在其hasNext()方法返回false之前遍历Integer.MAX_VALUE + 1值。
但是，Collection是Iterable的一种特殊形式。因为一个Collection不能有超过Integer.MAX_VALUE个元素(通过size()方法)，所以很自然地假定它的Iterator对象不会遍历这么多的元素。
因此，通过接受Collection而不是Iterable，您的类可以在一定程度上保证传入的元素数量。如果您的类本身就是一个Collection，那么这一点尤其可取。
这只是我的两个观点。
Stack Overflow用户
发布于 2012-11-04 04:33:12
Spring Data JPA的用户会发现Repositories返回Iterable<T>.类型的集合
在我过去参与的使用Spring的项目中，我发现检索后对集合进行操作的需要通常要求在业务层中使用Iterable<T>而不是Collection<T>，以便从集合中选择一个对象T。
所有集合都是Iterable (即扩展Collection接口的接口，所以不是Map!)，因此在业务层中使用Iterable仅仅是通过其超类型引用集合的一种情况，并且仍然允许使用for-each进行迭代。
或者，Google Guava和Apache Commons等流行的第三方API为此目的提供了方便的方法。
https://stackoverflow.com/questions/1159797
复制相似问题