Tutorial: Access Your Stored Java Objects with the Iterator Design Pattern:

UML Diagram

Figure 2: The UML diagram for the Iterator design pattern.

The diagram contains five classes:

• The Iterator interface declares methods hasNext() and next().
• The concrete BaseballIterator class implements hasNext() and next() for the data structure that stores baseball teams. (Likewise, the concrete FootballIterator class implements hasNext() and next() for the data structure that stores football teams.)
• The SportsTeams interface declares the iterator() method. This method returns an Iterator object—an object with the appropriate hasNext() and next() methods. In the sports application, an "appropriate" method is one that works with either a List<Sports> object or a Sports[] array depending on the kind of team (baseball or football).

In the official GoF book's lingo, an interface such as SportsTeams is called an aggregate. An aggregate houses a group of objects, perhaps a Java collection of some kind (an ArrayList of baseball teams, for example). The iterator's job is to traverse the items that the aggregate stores. Now, back to the UML diagram in Figure 2:

• The concrete BaseballTeams class implements the iterator() method for the data structure that stores baseball teams. (Likewise, the concrete FootballTeams class implements iterator() for the data structure that stores football teams.)
• The SportsApp class, the client application, uses aggregates and their iterators.

Implementing the Iterator Design Pattern

public interface Iterator<T> {
	public boolean hasNext();
	public T next();
	}

The following code defines an aggregate interface. This particular aggregate contains teams.

public interface SportsTeams {
	public void buildTeamList();
	public Iterator<Sports> iterator();
	}

The next order of business is to create concrete classes from the Iterator interface. The classes are in Listing 7 and 8.

In Listing 7 the BaseballIterator class has its own baseballList—an instance of java.util.List<Sports>. In Listing 8, the FootballIterator class has its own footballList —an instance of Sports[]. The use of instances is called composition. The alternative to composition is subclassing, in which BaseballIterator and FootballIterator are subclasses of Sports collections. For the Iterator pattern, composition is much better than subclassing. The BaseballIterator and FootballIterator classes use composition instead of subclassing.

Listing 4 and Listing 5 don't use the Iterator pattern. The following code snippets contain two different getTeamList() methods:

public List<Sports> getTeamList() // baseball
public Sports[] getTeamList() // football

public Iterator<Sports> iterator() // both baseball and football

In both Listing 9 and 10, the iterator() method returns an appropriate concrete iterator. In Listing 9 the method returns a BaseballIterator, and in 10 the method returns a FootballIterator. Using the Iterator pattern, the code buries the ugly details (baseball versus football? List versus array?) beneath the surface.

The original Sports, Baseball, and Football classes don't change at all when you adopt the Iterator Design pattern. But the client application (formerly Listing 6) changes a bit. The revised client application is in Listing 11.

When you execute the code in Listing 11 (the good code) you get the output of Figure 1—the same as the output of Listing 6 (also known as "the bad code"). But when other developers read the code in Listing 11, they know nothing about the data structures lurking behind the scenes. Unlike Listing 6, the code of Listing 11 completely masks the implementations of BaseballTeams and FootballTeams. The masking is especially helpful when classes (like BaseballTeams and FootballTeams) have different underlying implementations.

So What? The Java API Already Has Iterators

Resources

• Design Patterns—Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. ISBN 0-201-63361-2.
• Head First Design Patterns, by Eric and Elisabeth Freeman. ISBN 0-596-00712-4.
• Object-Oriented Software Construction, by Bertrand Meyer. ISBN 0-13-629155-4.
• Data and Object Factory

About the Authors