2

So, as the title asks, can Java Streams be considered an implementation of the Iterator pattern?

Can we consider that the .stream() call on a Collection create some sort of an iterator which allows you to parse the elements of that Collection, without actually exposing the representation of the Collection? (Which is what the Iterator Pattern implies, if I am not mistaking)

EDIT: to avoid confusion, please note that I am not interested in Java's Iterator interface, I just want to know if Java Streams can be considered an implementation of the Iterator Design Pattern, and why?

Marcu Daniel
  • 85
  • 2
  • 11
  • 3
    Does this answer your question? [Iterator versus Stream of Java 8](https://stackoverflow.com/questions/31210791/iterator-versus-stream-of-java-8) – Hadi J May 22 '20 at 14:34
  • @HadiJ this is a useful comparison between Java's Iterator and Stream, with advantages and drawbacks of both of them, but I would actually be more interested in if we can actually consider Java's Stream as a valid implementation of the Iterator Design Pattern, and why? :D – Marcu Daniel May 22 '20 at 14:39

1 Answers1

2

Can we consider that the .stream() call on a Collection create some sort of an iterator?

Yes we can! But the interesting question is, what sort of an iterator is it? The Iterator Design Pattern was originally published in the GoF book. On page 260 it states,

Iterator has many implementation variants and alternatives.

We might not recognize a stream as an iterator, because (in Java) we are so used to seeing the version of the pattern where the client explicitly calls next() and hasNext(). Streams are clearly not that version of the Iterator pattern, so what are they?

Who controls the iteration? A fundamental issue is deciding which party controls the iteration, the iterator or the client that uses the iterator. When the client controls the iteration, the iterator is called an external iterator, and when the iterator controls it, the iterator is an internal iterator. Clients that use an external iterator must advance the traversal and request the next element explicitly from the iterator. In contrast, the client hands an internal iterator an operation to perform, and the iterator applies that operation to every element in the aggregate.

There can be no doubt the Java Stream API was designed with the Iterator pattern in mind, and particularly the internal version of the pattern, because Stuart Marks and Brian Goetz have both graciously posted about their design decisions, here on SO. Stuart mentions how the initial prototype was based on Iterable itself. That was insufficient for parallel processing, and Brian describes how the ultimate implementation of the Stream API is now based on Spliterator.

So a Stream is still an iterator, but an internal iterator as opposed to the older Java APIs like Iterator and Enumeration.

jaco0646
  • 15,303
  • 7
  • 59
  • 83