Design Patterns: IteratorBlog

Introduction

This post gives a brief overview about the Iterator Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML.

The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML diagram. Then, the second part provides the PlantUML code for the diagram so that these posts can also be used as a source of design patterns in PlantUML syntax.

What is the Iterator Pattern?

According to Wikipedia, the iterator pattern is a design pattern in which an iterator is used to traverse a container and access the container’s elements. The iterator pattern decouples algorithms from containers; in some cases, algorithms are necessarily container-specific and thus cannot be decoupled.

What problems can the Iterator design pattern solve?

The elements of an aggregate object should be accessed and traversed without exposing its representation (data structures). New traversal operations should be defined for an aggregate object without changing its interface. Defining access and traversal operations in the aggregate interface is inflexible because it commits the aggregate to particular access and traversal operations and makes it impossible to add new operations later without having to change the aggregate interface.

What solution does the Iterator design pattern describe?

Define a separate (iterator) object that encapsulates accessing and traversing an aggregate object. Clients use an iterator to access and traverse an aggregate without knowing its representation (data structures). Different iterators can be used to access and traverse an aggregate in different ways. New access and traversal operations can be defined independently by defining new iterators.

UML Diagram

The following diagram shows the Iterator Pattern in UML notation. It is based on the corresponding chapter in the book “Head First Design Patterns“:

You can click on the diagram to open it online in Pladitor.

Diagram Sources

Here are the diagram sources:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

@startuml

hide empty fields
hide empty methods

class Aggregate <<interface>>
class Client
class Iterator <<interface>>
together {
    class ConcreteAggregate
    class ConcreteIterator
}

Aggregate : createIterator()
ConcreteAggregate : createIterator()
Iterator : hasNext()
Iterator : next()
Iterator : remove()
ConcreteIterator : hasNext()
ConcreteIterator : next()
ConcreteIterator : remove()

Aggregate <- Client
Client -> Iterator
ConcreteAggregate -> ConcreteIterator
Iterator <|.. ConcreteIterator
Aggregate <|.. ConcreteAggregate

note top of Aggregate
Having a common interface for your
aggregates is handy for your client;
it decouples your client from the
implementation of your collection of objects.
end note

note bottom of ConcreteAggregate
The ConcreteAggregate
has a collection of
objects and implements
the method that
returns an Iterator
for its collection.
end note

note "Each ConcreteAggregate\nis responsible for\ninstantiating a\nConcreteIterator that\ncan iterate over its\ncollection of objects." as n1
ConcreteAggregate .. n1
n1 .. ConcreteIterator

note bottom of ConcreteIterator
The ConcreteIterator is
responsible for managing
the current position of
the iteration.
end note

note top of Iterator
The Iterator interface
provides the interface
that all iterators
must implement, and
a set of methods
for traversing over
elements of a collection.
Here we are using the
java.util.Iterator. If you
do not want to use Java’s
Iterator interface, you
can always create your
own.
end note
@enduml

Open this diagram online with Pladitor.