Iterator Pattern
Iterator: start from the problem
See the responsibilities
A caller needs to visit available records but should not depend on the collection’s internal storage layout. Later the collection may filter or page those records differently.
This is a behavioral pattern lesson. Follow the responsibilities, inspect the small JavaScript example and compare the design choices. The example is local teaching code; its boundary is explained before you apply the idea to a real service.
What you’ll learn
- Explain the problem Iterator addresses and the roles involved.
- Follow the example and distinguish this pattern from nearby alternatives.
- Choose when the benefit justifies the extra responsibilities and testing.
How the responsibilities work
Iterator provides sequential access through a traversal contract without exposing the whole representation. The collection defines how traversal progresses. The caller consumes values through operations such as next or a language’s iteration protocol.
The example supplies a JavaScript iterable that yields only available rows. The caller uses for-of and does not perform its own array indexing. Traversal order and mutation behaviour still need explicit rules.
Follow a small example
Read the JavaScript from top to bottom and compare the expected output. The values are chosen to make this pattern’s responsibility visible. This example runs in one local execution context; it does not create remote services, durable storage or production access controls.
JavaScript · local teaching example
const catalog = {
rows: [{name: 'red', available: true}, {name: 'blue', available: false}],
*[Symbol.iterator]() {
for (const row of this.rows) if (row.available) yield row.name;
}
};
for (const name of catalog) console.log(name);Expected output
redChoose a design and inspect the consequence
Compare the design choices
Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.
This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.
Apply the pattern to two situations. Select one option in each situation to build a decision record. Every option and its consequence stays visible, and you can change your choices.
When it helps—and what it costs
Use it when consumers need a consistent traversal interface over different representations or lazy sequences. A server-side paginated API needs a related but explicit cursor contract.
Define what happens if the collection changes during traversal. A live iterator, a snapshot and a paginated remote cursor can give different results. Lazy remote iteration can make each next step an I/O operation with failures.
Distinguish the neighbouring patterns
Composite represents a tree; Iterator traverses a collection. Visitor applies an operation across typed nodes and may itself use traversal.
Follow tree representation, operations across node types, explicit request and pagination contracts to compare the specific responsibility before combining patterns.
Check your pattern reasoning
Check your pattern reasoning
Name the responsibility before choosing the pattern
For Iterator, describe the problem, the participating roles and the observable contract. Use the example as a starting point and test the boundaries identified in the trade-offs. A pattern name alone does not establish correctness or performance.
Return to the design-pattern guide to compare families, or apply the idea alongside explicit request and pagination contracts.
Reaching the recap and completing the quizzes are separate milestones.