Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
"Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation." (Gamma, E., R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 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 dont want to bloat the List interface with operations for different traversals, even if you could anticipate the ones well 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 lists elements. An iterator object is responsible for keeping track of the current element; it knows which elements have been traversed already. For example, a List class would call for a ListIterator . Before you can instantiate ListIterator, you must supply the List to traverse. Once you the have ListIterator instance, you can access the lists elements sequentially. The CurrentItem operation returns the current element in the list, First initializes the current element to the first element, Next advances the current element to the next element, and IsDone tests whether weve advanced beyond the last element--were finished with the traversal. Separating the traversal mechanism from the List object lets us define iterators for different traversal policies without enumerating them in the List interface. For example, a FilteringListIterator might provide access only to those elements that satisfy specific filtering constraints. Lets assume that we have a SkipList (a probabilistic data structure with characteristics similar to balanced trees) implementation of list. We want to write code that works for both List and SkipList objects. Define an AbstractList class that provides a common interface for manipulating lists. 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. To create the iterator, we make the list objects responsible for creating their corresponding iterator. This requires an operation like CreateIterator (a Factory Method pattern) through which clients request an Iterator object.
This pattern has been used on the following systems: Most collection class libraries offer iterators in one form or another. The Booch components provides both a fixed size and dynamically growing implementation of a queue. The queue interface is defined by an abstract Queue class.To support polymorphic iteration over the different queue implementations, the queue iterator is implemented in the terms of the abstract Queue class interface. (Booch, G., Object-Oriented Analysis and Design with Applications. Benjamin/Cummings, Redwood City, CA, 1994. Second Edition.) ObjectWindows 2.0 provides a class hierarchy of iterators for containers. Iteration can be done over different container types in the same way. The iteration syntax relies on overloading the postincrement operator ++ to advance the iteration. (Borland International, Inc., Scotts Valley, CA. A Technical Comparison of Borland Object Windows 2.0 and Microsoft MFC 2.5, 1994.)
Composite, Factory Method, and Memento patterns
Factory Method pattern, Composite pattern, Iterator pattern, Memento pattern, behavioral patterns, Gamma patterns, Cursor pattern, encapsulation (object access & traversal), sequential element access, polymorphic iteration, aggregate traversal
any system requiring traversal of lists of objects in multiple waysany system with large number of whole-part object relationships
need to protect clients from knowing if an object is a whole or a part
provides multiple versions of traversing whole-part relationshipssimplifies adding new parts in whole-part relationshipssimplifies navigation of whole-part hierarchiessimplifies the client - permitting the client to treat whole or part objects generically
Test driver Test.javaSimple implementation of the pattern - Iterator class. Iterator.javaSimple implementation of the pattern - ConcreteIterator class. ConcreteIterator.javaSimple implementation of the pattern - ConcreteAggregate class. ConcreteAggregate.javaSimple implementation of the pattern - Aggregate class. Aggregate.javaTest driver testiterator.cppSimple implementation of the pattern - Iterator classes. iterator.cppSimple implementation of the pattern. iterator.h