I. Iterator — Behavioral Pattern

Iterator provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation — whether that's a slice, a linked list, a tree, or something else. The collection exposes a CreateIterator() method that returns an object satisfying a common Iterator interface, and the client walks the collection using only HasNext() and Next().

This solves the problem of traversal logic leaking into client code. Without Iterator, the client has to know whether the underlying store is a slice (needs an index), a map (needs a different traversal), or a tree (needs recursion) — and that knowledge gets duplicated everywhere the collection is walked. Iterator moves the traversal state into a small, separate cursor object, so the client's loop is always the same two-method dance, no matter what's actually being iterated.

It's the same shape as Go's own range keyword under the hood, or a database cursor that fetches one row at a time — the caller stays generic, the traversal mechanics stay hidden behind the cursor.

II. Real-world Example

A coffee shop's menu, where a client wants to print every item on the menu without knowing how the menu stores them:

1. Menu (Collection) — holds a slice of MenuItem and exposes AddItem(name, price) plus CreateIterator(), which returns a fresh MenuIterator positioned before the first item.

2. Collection (interface) — declares CreateIterator() Iterator, the contract any iterable type must implement.

3. Iterator (interface) — declares HasNext() bool and Next() MenuItem, the contract every cursor must implement.

4. MenuIterator — the concrete cursor. It keeps a reference to the Menu and an index, and walks the items one at a time.

5. MenuItem — a simple value type: Name and Price.

The client only ever calls menu.CreateIterator(), then loops with HasNext()/Next() — it never touches menu.items directly.

III. Implementation

iterator.go

1package iterator
2
3type Iterator interface {
4	HasNext() bool
5	Next() MenuItem
6}
7
8type Collection interface {
9	CreateIterator() Iterator
10}

menu.go

1package iterator
2
3type MenuItem struct {
4	Name  string
5	Price float64
6}
7
8type Menu struct {
9	items []MenuItem
10}
11
12func NewMenu() *Menu {
13	return &Menu{}
14}
15
16func (m *Menu) AddItem(name string, price float64) {
17	m.items = append(m.items, MenuItem{Name: name, Price: price})
18}
19
20func (m *Menu) CreateIterator() Iterator {
21	return &MenuIterator{menu: m}
22}

menu_iterator.go

1package iterator
2
3type MenuIterator struct {
4	menu  *Menu
5	index int
6}
7
8func (i *MenuIterator) HasNext() bool {
9	return i.index < len(i.menu.items)
10}
11
12func (i *MenuIterator) Next() MenuItem {
13	item := i.menu.items[i.index]
14	i.index++
15	return item
16}

main.go (usage)

1menu := iterator.NewMenu()
2menu.AddItem("Espresso", 3.00)
3menu.AddItem("Latte", 4.50)
4menu.AddItem("Croissant", 2.75)
5
6menuIterator := menu.CreateIterator()
7for menuIterator.HasNext() {
8	item := menuIterator.Next()
9	fmt.Printf("%s: %.2f\n", item.Name, item.Price)
10}

IV. Explain the example above

1. iterator.NewMenu() creates an empty Menu.

2. Three AddItem calls append MenuItem{Espresso, 3.00}, {Latte, 4.50}, and {Croissant, 2.75} to the internal slice — the client never sees this slice directly.

3. menu.CreateIterator() returns a *MenuIterator with index = 0, holding a reference back to menu.

4. The for menuIterator.HasNext() loop repeatedly checks index < len(menu.items), and each Next() call returns the item at the current index before advancing it.

5. Once index reaches the length of the slice, HasNext() returns false and the loop ends.

Running it produces:

1*** Example Iterator ***
2Espresso: 3.00
3Latte: 4.50
4Croissant: 2.75
5*** End of Iterator ***

Notice that the client code never indexes into a slice or checks a length itself — it only calls HasNext() and Next(). If Menu later switched its internal storage to a linked list or a map, MenuIterator would change, but the client's loop would not.

V. Conclusion

Iterator earns its keep when a collection's internal representation is non-trivial — a tree, a graph, a paginated API response — or likely to change, and you want traversal code that doesn't care which. It also matters when several different collection types need to expose the same traversal contract, so client code can loop over any of them identically.

For a single slice that's only ever looped over once, in one place, Go's built-in range is simpler and the extra interface is pure ceremony. Iterator pays off once traversal logic needs to be reused across multiple collection types, or once the collection's storage might change without client code needing to change too.

No pattern is universally superior.

VI. References

• Go Design Patterns (Mario Castro Contreras)

• Source code on GitHub