接受和返回类型的 Java 方法Iterable<T>
非常常见。我看到的问题是 Iterator接口非常有限,它要么需要将 Iterable 重构为可用的数据结构,要么强制用户执行 Iterable 的多次遍历,从而增加执行时间。
有人可以纠正我吗?Iterables 是否像我认为的那样糟糕?如果您被迫使用它们,是否有任何技术可以用来解决 Iterables 的限制?
接受和返回类型的 Java 方法Iterable<T>
非常常见。我看到的问题是 Iterator接口非常有限,它要么需要将 Iterable 重构为可用的数据结构,要么强制用户执行 Iterable 的多次遍历,从而增加执行时间。
有人可以纠正我吗?Iterables 是否像我认为的那样糟糕?如果您被迫使用它们,是否有任何技术可以用来解决 Iterables 的限制?
关于接受这Iterable<T>
显然是一件好事。这意味着您几乎可以将任何数据结构传递给它——它只需要实现非常简单的Iterable<T>
接口。这使得代码更容易重用。
返回一个Iterable<T>
优点是方法的实现可以改变——可能使用更有效的数据结构,或者通过在请求时延迟生成结果(例如从磁盘流式传输)。在不破坏客户端的情况下更改实现很容易,因为它们只依赖于Iterable<T>
接口。如果您公开了 aList<T>
那么您不能确定您的客户将按顺序访问数据。
您是对的,如果您需要多次访问结果,那么首先将数据复制到不同的结构中是有意义的。但只有您知道哪个特定集合对您的特定情况最有用。有时它可能是一个ArrayList
. 其他时候,您可能更喜欢将项目存储在HashMap
. 因此,无论如何,您通常都必须将数据复制到新的数据结构中。
此外,在JDK 8中,我们将看到Iterable
界面上的重大改进。
随着扩展方法的添加,接口将提供默认实现,并且将添加许多新函数以提供能够接受lambda 表达式的高阶函数的等价物,此外,由于它们的迭代性质,惰性求值将被实现,而不是提到并行性,所以现在很流行。
接受Iterable< T >
对您的客户来说是一项很棒的服务。
退回它通常对他们不利。如果您不打算改变对使用什么集合来实现结果的想法,那么您应该尽可能具体。