Design Patterns : Elements of Reusable Object-Oriented Software

Design Patterns: Elements of Reusable Object-Oriented Software 
80 
non-textual glyphs. We'd have tochange the Traversal enumeration to include 
something likeTEXTUAL_PREORDER. 
We'd like to avoid changing existing declarations.Putting the traversal mechanism 
entirely in the Glyph class hierarchymakes it hard to modify or extend without 
changing lots of classes.It's also difficult to reuse the mechanism to traverse 
other kinds ofobject structures. And we can't have more than one traversal 
inprogress on a structure. 
Once again, a better solution is to encapsulate the concept thatvaries, in this 
case the access and traversal mechanisms. We canintroduce a class of objects called 
iterators
whose solepurpose is to define different sets of these mechanisms. We 
can useinheritance to let us access different data structures uniformly andsupport 
new kinds of traversals as well. And we won't have to changeglyph interfaces or 
disturb existing glyph implementations to do it. 
Iterator Class and Subclasses 
We'll use an abstract class called 
Iterator
todefine a general interface for access 
and traversal. Concretesubclasses like 
ArrayIterator
and
ListIterator
implement 
the interface to provideaccess to arrays and lists, while 
PreorderIterator
,
PostorderIterator
, and the like implement differenttraversals 
on specific structures. Each Iterator subclass has areference to the structure 
it traverses. Subclass instances areinitialized with this reference when they 
are created. Figure 2.13 illustrates theIterator class along with several 
subclasses. Notice that we'veadded a CreateIterator abstract operation to the 
Glyph classinterface to support iterators. 

---