Explore Iterator in Scala, when custom traversal boundaries still matter, and how to expose ordered access without leaking collection internals.
Iterator pattern: A behavioral pattern that provides sequential access to elements without exposing the underlying representation directly.
Scala already has a rich collections and iterator API, so the classic pattern often appears more as an interface boundary than as a custom hand-built object hierarchy.
Iterator remains relevant when callers should consume data without learning:
In those cases, the iterator is not just a loop helper. It is a traversal contract.
A lot of explicit Iterator pattern code is unnecessary in Scala because collections already provide traversal well. If your data is naturally a strict in-memory collection, returning:
ListVectorIteratorLazyListmay be all you need.
The pattern becomes more interesting when traversal has behavior beyond “walk this list.”
Custom iterator boundaries often matter for:
The iterator then represents not only element order, but also how data is fetched or materialized over time.
Scala gives several options, and choosing the wrong one can confuse callers:
Iterator for one-pass consumptionLazyList for lazily computed reusable structureIf the iteration performs effects or depends on open resources, a stronger streaming abstraction may be more honest than a plain iterator.
A custom iterator adds code without protecting any meaningful boundary.
Callers treat the result like a reusable collection when it is really a cursor-like traversal.
Effects, cancellation, and resource ownership can outgrow what a plain iterator communicates.
Use Scala’s built-in collection abstractions by default. Reach for Iterator as a boundary when sequential consumption matters and representation should stay hidden. If traversal is effectful or resource-bound, expose that honestly instead of pretending it is an ordinary collection walk.