Iterator pattern: The LePUS3 & Class-Z companion to the GoF
The 'Gang of Four' Companion:

Iterator Design Pattern

Formal specification of design patterns in LePUS3 and Class-Z

Print this document

This page is part of the The 'Gang of Four' Companion dedicated to the formal specification in LePUS3 and Class-Z of patterns from the 'Gang of Four' catalogue [Gamma et al 1995].



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?):

Iterator in UML


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:

Iterator in LePUS3
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
Iterator implementation modelled in LePUS3
using 1-dimensional hierarchy constants (legend)
Iterator implementation
Iterator implementation modelled in LePUS3
using 1-dimensional class constants (legend)
Iterator implementation
Iterator implementation modelled in LePUS3
using 0-dimensional class (signature) constants (legend)