blocks|key|1830958|text|根据最小意外原则，您应该模拟Java集合模式，并采用集合构造函数arg。这会让你后面的人稍微不那么困惑。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1830959|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

According to the principle of least surprise, you should emulate the Java collection pattern and take a Collection constructor arg. It will make the people who come after you slightly less puzzled.

blocks|key|1831024|text|许多集合类型在Iterable+(它在1.5中才引入)之前就已经存在了-几乎没有理由添加一个构造函数来接受Iterable<T>和Collection，但是更改现有的构造函数将是一个破坏性的变化。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1831025|就我个人而言，如果Iterable<T>允许你做任何你想做的事情，我会使用它。对于调用者来说，它更加灵活，特别是它允许您使用Google+Java+Collections+(毫无疑问还有类似的库)进行相对简单的过滤/投影等操作。|1831026|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.oracle.com/javase/8/docs/api/java/lang/Iterable.html|1|https://docs.oracle.com/javase/8/docs/api/java/util/Collection.html^0|7|8|1H|B|1T|A|7|8|0|1T|A|1|0|9|B|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]|$9|U|A|V|B|C]|$9|W|A|X|B|C]]|D|@$9|Y|A|Z|1|10]|$9|11|A|12|1|13]]|E|$]]|$1|F|3|G|5|6|7|14|8|@$9|15|A|16|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|17|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]|P|$5|K|L|M|E|$N|Q]]]]

Many of the collection types existed before <a href="https://docs.oracle.com/javase/8/docs/api/java/lang/Iterable.html" rel="noreferrer"><code>Iterable&lt;T&gt;</code></a> (which was only introduced in 1.5) - there was little reason to add a constructor to accept <code>Iterable&lt;T&gt;</code> as well as <a href="https://docs.oracle.com/javase/8/docs/api/java/util/Collection.html" rel="noreferrer"><code>Collection&lt;T&gt;</code></a> but changing the existing constructor would have been a breaking change.

Personally I would use <code>Iterable&lt;T&gt;</code> if that allows you to do everything you want it to. It's more flexible for callers, and in particular it lets you do relatively easy filtering/projection/etc using the Google Java Collections (and no doubt similar libraries).

blocks|key|2045264|text|你是对的，因为询问你所需要的东西的最一般形式被认为是一种好的实践。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2045265|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You're correct, as it's considered good practice to ask for the most general form of what you need.

blocks|key|1831238|text|尽可能使用最通用的接口。既然你要做的就是迭代，那么我会说Iterable是可行的(因为它允许懒惰的迭代器，等等)。您并不关心迭代器是从哪里来的，所以不要在必要时对其进行过多的限制。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1831239|entityMap^0|S|8|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

Use the most general interface that you can. Since all you're going to do is iterate, then I would say <code>Iterable</code> is the way to go (since it allows lazy iterators, etc.). You don't care where the iterator is coming from, so don't restrict it more than you have to.

blocks|key|1831326|text|如果你选择Collection，那么你的类只能从一个集合初始化，如果你选择Iterable，那么你可以从集合或iterable进行初始化。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1831327|由于两者的工作量和性能是相同的，所以在构造函数中接受Iterable是完全有意义的。|1831328|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If you go for Collection, then your class can be initialised from a collection only, if you go for Iterable, then you can initialise from either collection or iterable.

As the effort and performance for both is going to be the same, it makes total sense to accept Iterable in the constructor.

blocks|key|2045722|text|Iterable生成Iterator对象。根据定义，Iterator对象是迭代的。注意，Iterator接口并不保证在hasNext()返回false之前next()可以被调用多少次。Iterator可能会在其hasNext()方法返回false之前遍历Integer.MAX_VALUE+%2B+1值。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2045723|但是，Collection是Iterable的一种特殊形式。因为一个Collection不能有超过Integer.MAX_VALUE个元素(通过size()方法)，所以很自然地假定它的Iterator对象不会遍历这么多的元素。|2045724|因此，通过接受Collection而不是Iterable，您的类可以在一定程度上保证传入的元素数量。如果您的类本身就是一个Collection，那么这一点尤其可取。|2045725|这只是我的两个观点。|2045726|entityMap^0|0|8|A|8|Q|8|18|8|1N|9|1Y|5|25|6|2K|8|2X|9|3A|5|3J|L|0|3|A|E|8|Y|A|1D|H|20|6|2K|8|0|7|A|K|8|1P|A|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]|$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]|$9|W|A|X|B|C]|$9|Y|A|Z|B|C]|$9|10|A|11|B|C]|$9|12|A|13|B|C]|$9|14|A|15|B|C]|$9|16|A|17|B|C]|$9|18|A|19|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1A|8|@$9|1B|A|1C|B|C]|$9|1D|A|1E|B|C]|$9|1F|A|1G|B|C]|$9|1H|A|1I|B|C]|$9|1J|A|1K|B|C]|$9|1L|A|1M|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1N|8|@$9|1O|A|1P|B|C]|$9|1Q|A|1R|B|C]|$9|1S|A|1T|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|1U|8|@]|D|@]|E|$]]|$1|L|3|-4|5|6|7|1V|8|@]|D|@]|E|$]]]|M|$]]

An <code>Iterable</code> produces <code>Iterator</code> objects. An <code>Iterator</code> object, by definition, iterates. Notice, that the <code>Iterator</code> interface makes no promise as to how many times <code>next()</code> can be called before <code>hasNext()</code> returns <code>false</code>. An <code>Iterator</code> could possibly iterate over <code>Integer.MAX_VALUE + 1</code> values before its <code>hasNext()</code> method returns <code>false</code>.

However, a <code>Collection</code> is a special form of <code>Iterable</code>. Because a <code>Collection</code> cannot have more than <code>Integer.MAX_VALUE</code> elements (by virtue of the <code>size()</code> method), it is naturally presumed that its <code>Iterator</code> objects will not iterate over this many elements.

Therefore, by accepting a <code>Collection</code> rather than an <code>Iterable</code>, your class can have some guarantee over how many elements are being passed in. This is especially desirable if your class is itself a <code>Collection</code>.

Just my two cents...

blocks|key|1831629|text|一些构造函数，例如ArrayList(集合c)，使用集合的toArray()方法来提高效率。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1831630|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Some constructors, e.g. ArrayList(Collection c), use the toArray() method of Collection for efficiency.

blocks|key|1831812|text|参见“为什么如此强调迭代器和迭代器？”在Google+Collection+FAQ上为首选迭代器提供了一个很好的论据，特别是在处理大量数据时。一个可能有帮助的类比是考虑只进只读游标和可滚动游标之间的区别。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1831813|entityMap|0|LINK|mutability|MUTABLE|url|http://code.google.com/p/google-collections/wiki/Faq^0|K|L|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

See "Why so much emphasis on Iterators and Iterables?" on the <a href="http://code.google.com/p/google-collections/wiki/Faq" rel="nofollow noreferrer">Google Collection FAQ</a>
for a decent argument for preferring Iterators, especially when dealing with a lot of data. One analogy that might help is to think the difference between forward-only read-only cursors and scrollable cursors.

blocks|key|2046304|text|Spring+Data+JPA的用户会发现Repositories返回Iterable<T>.类型的集合|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2046305|在我过去参与的使用Spring的项目中，我发现检索后对集合进行操作的需要通常要求在业务层中使用Iterable<T>而不是Collection<T>，以便从集合中选择一个对象T。|2046306|所有集合都是Iterable+(即扩展Collection接口的接口，所以不是Map!)，因此在业务层中使用Iterable仅仅是通过其超类型引用集合的一种情况，并且仍然允许使用for-each进行迭代。|2046307|2046308|或者，Google+Guava和Apache+Commons等流行的第三方API为此目的提供了方便的方法。|2046309|entityMap^0|0|F|L|C|Z|C|0|9|6|1B|B|1P|D|2F|1|0|6|8|J|A|13|3|1I|8|2H|8|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]|$9|T|A|U|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|V|8|@$9|W|A|X|B|C]|$9|Y|A|Z|B|C]|$9|10|A|11|B|C]|$9|12|A|13|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|14|8|@$9|15|A|16|B|C]|$9|17|A|18|B|C]|$9|19|A|1A|B|C]|$9|1B|A|1C|B|C]|$9|1D|A|1E|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|1F|8|@]|D|@]|E|$]]|$1|K|3|L|5|6|7|1G|8|@]|D|@]|E|$]]|$1|M|3|-4|5|6|7|1H|8|@]|D|@]|E|$]]]|N|$]]

Users of <code>Spring Data JPA</code> will find that the <code>Repositories</code> return collections of type <code>Iterable&lt;T&gt;.</code> 

On projects I've worked on in the past that use <code>Spring</code>, I've found that the need to operate on a Collection after retrieval has often dictated that <code>Iterable&lt;T&gt;</code> is used in the business layer rather than <code>Collection&lt;T&gt;</code> in order to select an Object <code>T</code> from the collection.

All Collections are <code>Iterable</code> (that is the interfaces which extend the <code>Collection</code> interface, so not <code>Map</code>!), so using <code>Iterable</code> in the business layer is merely a case of referring to a Collection by its super type and still allows the use of <code>for-each</code> to iterate.

If you need to manipulate the contents of a collection, a convenience method would allow you to populate a new <code>Collection</code>, so you can make use of <code>contains()</code>, <code>remove()</code>, etc with the original collection data.

Alternatively, convenience methods are provided for this purpose by popular third party APIs such as Google Guava and Apache Commons.

What are the considerations of using <a href="https://docs.oracle.com/javase/8/docs/api/java/lang/Iterable.html" rel="noreferrer"><code>Iterable&lt;T&gt;</code></a> vs. <a href="https://docs.oracle.com/javase/8/docs/api/java/util/Collection.html" rel="noreferrer"><code>Collection&lt;T&gt;</code></a> in Java?

For example, consider implementing a type that is primarily concerned with containing a collection of <code>Foo</code>s, and some associated metadata. The constructor of this type allows one-time initialisation of the object list. (The metadata can be set later.) What type should this constructor accept? <code>Iterable&lt;Foo&gt;</code>, or <code>Collection&lt;Foo&gt;</code>?

What are the considerations for this decision?

Following the pattern set forth by library types such as <code>ArrayList</code> (which can be initialised from any <code>Collection</code>, but not an <code>Iterable</code>) would lead me to use <code>Collection&lt;Foo&gt;</code>.

But why not accept <code>Iterable&lt;Foo&gt;</code>, given that this is is sufficient for the initialisation needs? Why demand a higher level of functionality (<code>Collection</code>) from the consumer, than what is strictly necessary (<code>Iterable</code>)?

When should I accept a parameter of Iterable<T> vs. Collection<T> in Java?

Java

在Java中使用与使用的注意事项是什么？例如，考虑实现一个主要涉及包含Foo集合和一些相关元数据的类型。此类型的构造函数允许一次性初始化对象列表。(元数据可以稍后设置。)此构造函数应接受什么类型？Iterable<Foo>还是Collection<Foo>这一决定的考虑因素是什么？遵循诸如ArrayList (可以从任...

问在java语言中，什么时候应该接受Iterable<T>和Collection<T>的参数？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在java语言中，什么时候应该接受Iterable<T>和Collection<T>的参数？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在java语言中，什么时候应该接受Iterable<T>和Collection<T>的参数？
EN