Iterator
Iterator separates traversal state from the collection being traversed. Independent iterators can walk the same collection without consuming one another’s position.
What you’ll understand
- Iterator separates traversal state from the collection being traversed. Independent iterators can walk the same collection without consuming one another’s position.
- Each iterator owns a cursor while sharing access to the underlying collection.
- Evaluate the tradeoff: Define what happens when the collection changes during iteration. Snapshot, fail-fast, and live iteration are different contracts; this example uses a stable collection.
Useful first: Classes and Objects
The idea and when to recognize it
Iterator separates traversal state from the collection being traversed. Independent iterators can walk the same collection without consuming one another’s position.
- Requirement: Two readers need to begin traversal of the same collection independently.
- Change to anticipate: Advance one reader twice and still let the second reader see the first value.
- Design goal: Each iterator owns a cursor while sharing access to the underlying collection.
Start with the concrete problem
Two readers need to begin traversal of the same collection independently.
Advance one reader twice and still let the second reader see the first value.
| Direct implementation | Revised design |
|---|---|
| Storing a single cursor on the collection makes one reader move every other reader. | Each iterator owns a cursor while sharing access to the underlying collection. |
| The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design. | Define what happens when the collection changes during iteration. Snapshot, fail-fast, and live iteration are different contracts; this example uses a stable collection. |
Responsibilities and contracts
Each iterator owns a cursor while sharing access to the underlying collection.
- Collection: Holds stable values. Public operations: iterator()
- Cursor: Owns traversal position. Public operations: next()
Read the design
Select a participant to inspect its responsibility and public operations. Follow the labeled relationships; an arrow indicates direction, while the legend distinguishes ownership, substitution, and temporary use.
Preparing the design walkthrough…
Follow the interaction
Choose a supplied workload and compare the direct and revised implementations. Step through the same operation in both languages. Object values are recorded after each highlighted statement; previous steps remain unchanged.
Preparing the design walkthrough…
Implementation and expected output
Read the complete example alongside its input and expected output. The implementation selector changes the displayed program; the language selector preserves your current scenario and playback position.
Preparing the design walkthrough…
Try the idea in another setting
Two views can independently page through the same immutable search result set.
- Name the new client contract before adapting the example.
- Identify which state belongs to each object and who controls its lifetime.
- Write one normal case and one boundary case before extending the design.
Tradeoffs and interview takeaways
Define what happens when the collection changes during iteration. Snapshot, fail-fast, and live iteration are different contracts; this example uses a stable collection.
Common mistake: Storing a single cursor on the collection makes one reader move every other reader.
- Explain the choice: Each iterator owns a cursor while sharing access to the underlying collection.
- Challenge your choice: Define what happens when the collection changes during iteration. Snapshot, fail-fast, and live iteration are different contracts; this example uses a stable collection.
- Describe a requirement that would make the simpler implementation sufficient.
Design challenge and knowledge check
Preparing the design walkthrough…