在给定迭代器的情况下使用 for-each 循环的惯用方法？

当增强的 for 循环（foreach 循环）被添加到 Java 中时，它可以处理数组或数组的目标Iterable.

for ( T item : /*T[] or Iterable<? extends T>*/ ) {
    //use item
}

这对于仅实现一种迭代类型的 Collection 类非常有用，因此具有单个iterator() method.

但当我想使用 Collection 类中的非标准迭代器时，我发现自己非常沮丧。例如，我最近试图帮助某人使用Deque作为 LIFO/堆栈，然后按 FIFO 顺序打印元素。我被迫这样做：

for (Iterator<T> it = myDeque.descendingIterator(); it.hasNext(); ) {
   T item = it.next();
   //use item
}

我失去了 for-each 循环的优点。这不仅仅是击键的问题。如果不需要的话，我不喜欢公开迭代器，因为很容易犯调用错误it.next()两次等

现在理想情况下，我认为 for-each 循环应该接受一个Iterator以及。但事实并非如此。那么在这种情况下有没有一种使用 for-each 循环的惯用方法呢？我也很想听到使用 Guava 等常见集合库的建议。

在没有辅助方法/类的情况下我能想到的最好的方法是：

for ( T item : new Iterable<T>() { public Iterator<T> iterator() { return myDeque.descendingIterator(); } } ) {
    //use item
}

哪个不值得使用。

我很想看到番石榴有类似的东西Iterables.wrap使这成为惯用语，但没有找到类似的东西。显然，我可以通过类或辅助方法推出我自己的迭代器包装器。还有其他想法吗？

Edit:作为旁注，任何人都可以给出一个有效的理由来解释为什么增强的 for 循环不应该只接受一个Iterator？这可能会对我接受当前的设计大有帮助。

为什么增强的 for 循环不只接受迭代器？

我想从各种答案中收集一些潜在原因，了解为什么 for-each 循环不简单地接受迭代器。

1. 方便：创建 for-each 循环的部分原因是为了方便执行给定集合中每个元素的操作的常见操作。它没有义务或意图取代迭代器的显式使用（显然如果你想删除元素，你需要对迭代器的显式引用）。
2. 可读性：for-each 循环for ( Row r : table )意味着非常具有可读性，如“对于表中的每一行“r”......”。看见for ( Row r : table.backwardsIterator() )破坏了可读性。
3. 透明度：如果一个对象既是Iterable and an Iterator，将会有什么行为？尽管制定一致的规则很容易（例如，Iterable 在 Iterator 之前），但行为对开发人员来说不太透明。此外，必须在编译时检查这一点。
4. 封装/范围：（我认为）这是最重要的原因。 for-each 循环旨在封装Iterator并将其范围限制为循环。这使得循环以两种方式“只读”：它不公开迭代器，这意味着没有任何（容易）有形的东西改变了其状态by循环，也不能改变操作数的状态in循环（就像您可以通过直接与迭代器交互一样remove()）。自己传递迭代器必然意味着迭代器被公开，从而使您失去循环的两个“只读”属性。