= Solution
The <iterator pattern> separates traversal state from the aggregate being traversed. A client asks whether another entry exists, then requests that entry, without knowing whether storage is an <array>, a <linked list> or another <data structure>. Distinct <iterators> have independent positions in a traversal.
In <Java>, declare `DataList implements Iterable<Point>` and provide `public Iterator<Point> iterator()`. The returned <iterator> implements `hasNext()` and `next()`; exhausted `next()` throws `NoSuchElementException`. This also permits an enhanced `for (Point p : data)` loop.<Java 8 iteration API documentation>[Iterable.iterator(), enhanced for support, and Iterator.next() exhaustion contract]{ref}
Returning `points.iterator()` directly would permit removal through that <iterator> and expose mutable stored `Point` instances. Part (e) instead returns an unmodifiable <iterator snapshot> containing fresh `Point` copies. That choice gives stable traversals and prevents <representation exposure>, with the tradeoff that a traversal does not see subsequent insertions. Thus
$$
\boxed{\texttt{Iterable<Point>}\ \text{creates independent}\ \texttt{Iterator<Point>}\ \text{traversals}.}
$$
Back to article page
