java - 为什么 Iterable<T> 不提供 stream() 和 parallelStream() 方法？

Question

我想知道为什么 Iterable接口(interface)不提供stream()和 parallelStream()方法。考虑以下类:

public class Hand implements Iterable<Card> {
    private final List<Card> list = new ArrayList<>();
    private final int capacity;

    //...

    @Override
    public Iterator<Card> iterator() {
        return list.iterator();
    }
}

它是Hand的一种实现，因为您可以在玩集换式卡牌游戏时手中有牌。

基本上它包装了 List<Card> ，确保最大容量并提供一些其他有用的功能。最好直接将其实现为 List<Card> .

现在，为了方便起见，我认为实现 Iterable<Card> 会很好。 ，这样如果你想循环它，你可以使用增强的 for 循环。 (我的 Hand 类还提供了一个 get(int index) 方法，因此我认为 Iterable<Card> 是合理的。)

Iterable接口(interface)提供以下内容(省略 javadoc):

public interface Iterable<T> {
    Iterator<T> iterator();

    default void forEach(Consumer<? super T> action) {
        Objects.requireNonNull(action);
        for (T t : this) {
            action.accept(t);
        }
    }

    default Spliterator<T> spliterator() {
        return Spliterators.spliteratorUnknownSize(iterator(), 0);
    }
}

现在你可以获得一个流:

Stream<Hand> stream = StreamSupport.stream(hand.spliterator(), false);

所以到真正的问题:

• 为什么 Iterable<T>不提供实现 stream() 的默认方法和 parallelStream() , 我看不出有什么可以使这不可能或不需要的？

我发现的一个相关问题如下:Why does Stream<T> not implement Iterable<T>?
奇怪的是，它暗示它以相反的方式去做。

Answer 1

这不是遗漏； 2013年6月EG名单有详细讨论。

专家组的权威讨论 Root 于this thread .

虽然 stream() 似乎“很明显”(即使对专家组来说，最初也是如此)似乎对 Iterable 有意义，事实是Iterable太笼统成了一个问题，因为明显的签名:

Stream<T> stream()

并不总是你想要的。一些事情是Iterable<Integer>宁愿让他们的流方法返回 IntStream ， 例如。但是把 stream()在层次结构中如此高的方法将使这成为不可能。因此，我们使制作 Stream 变得非常容易。来自 Iterable , 通过提供 spliterator()方法。 stream()的执行在 Collection只是:

default Stream<E> stream() {
    return StreamSupport.stream(spliterator(), false);
}

任何客户端都可以从 Iterable 获取他们想要的流。与:

Stream s = StreamSupport.stream(iter.spliterator(), false);

最后我们得出结论，添加 stream()至Iterable会出错。