Links

The Iterator design motif

The informal description: Excerpts from [Gamma et al. 1995] (adapted for this purpose):

Intent: Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

Structure: Original OMT diagram converted to UML (Why and How?):

Participants:

• Iterator: defines an interface for accessing and traversing elements.
• ConcreteIterator: implements the Iterator interface and keeps track of the current position in the traversal of the aggregate.
• Aggregate: defines an interface for creating an Iterator object.
• ConcreteAggregate: implements the Iterator creation interface to return an instance of the proper ConcreteIterator.

Collaborations: A ConcreteIterator keeps track of the current object in the aggregate and can compute the succeeding object in the traversal.

Formal specification

See also:

• Legend: Key to LePUS3 and Class-Z Symbols
• Reference Manual for LePUS3 & Class-Z
• Iterator in XML
• Modelling Design Patterns: Frequently-Asked Questions

Iterator in LePUS3 (legend)
Observer in Class-Z (legend)

Sample Implementations

Informal description: Collections and Iterators

From [Gamma et. al 1995]:

An aggregate object such as a list should give you a way to access its elements without exposing its internal structure. Moreover, you might want to traverse the list in different ways, depending on what you want to accomplish. But you probably don't want to bloat the List interface with operations for different traversals, even if you could anticipate the ones you will need. You might also need to have more than one traversal pending on the same list.

The Iterator pattern lets you do all this. The key idea in this pattern is to take the responsibility for access and traversal out of the list object and put it into an iterator object. The Iterator class defines an interface for accessing the list's elements. An iterator object is responsible for keeping track of the current element; that is, it knows which elements have been traversed already.

Notice that the iterator and the list are coupled, and the client must know that it is a list that's traversed as opposed to some other aggregate structure. Hence the client commits to a particular aggregate structure. It would be better if we could change the aggregate class without changing client code. We can do this by generalizing the iterator concept to support polymorphic iteration.

We define an AbstractList class that provides a common interface for manipulating lists. Similarly, we need an abstract Iterator class that defines a common iteration interface. Then we can define concrete Iterator subclasses for the different list implementations. As a result, the iteration mechanism becomes independent of concrete aggregate classes.

This design pattern, as informally described for lists above, can be seen implemented within the Java Collections framework. How this is done is presented below, and unless otherwise stated all classes reside within the package java.util.

Formal specification: Collections and Iterators

Specified in LePUS3 and Class-Z (see legend)

Iterator implementation modelled in LePUS3 using 1-dimensional hierarchy constants (legend)
Iterator implementation modelled in LePUS3 using 1-dimensional class constants (legend)
Iterator implementation modelled in LePUS3 using 0-dimensional class (signature) constants (legend)