Design Patterns in Ruby: Reaching into a Collection with the Iterator
This chapter is from the book
This chapter is from the book
This chapter is from the book
In Chapter 6, we looked at composites—objects that appear to be simple components but are actually made up of a collection of subcomponents. Of course, an object does not have to be a composite to know about collections of other objects. An Employee object might know about several dependents, or phone numbers, or, in the case of a well-paid executive, the addresses of many palatial estates. In this kind of situation, it would be helpful if we could sequence through all of the sub-objects without needing to know any of the details of how the aggregate object is storing them.
In this chapter, we will explore the Iterator pattern, a technique that allows an aggregate object to provide the outside world with a way to access its collection of sub-objects. We will see how iterators come in two basic flavors and learn how the Iterator pattern explains those funny-looking each loops that we encounter in Ruby.
External Iterators
The GoF tell us that the Iterator pattern will do the following:
Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation
In other words, an Iterator provides the outside world with a sort of movable pointer into the objects stored inside an otherwise opaque aggregate object.
If you are a Java programmer, iterators will be most familiar to you in the guise of the java.util.Iterator interface and its older brother, java.util.Enumeration. A typical use of the Java iterator is shown here:
ArrayList list = new ArrayList();
list.add("red");
list.add("green");
list.add("blue");
for( Iterator i = list.iterator(); i.hasNext();) {
System.out.println( "item: " + i.next());
}
Iterators also show up in slightly more unexpected places. For example, you can look at java.util.StringTokenizer as an iterator that allows you to run through all of the tokens in a string. Similarly, JDBC includes ResultSet, which allows us to iterate over each row in a SQL query result.
This style of iterator is sometimes referred to as an external iterator—“external” because the iterator is a separate object from the aggregate. We will see in a minute that this is not the only iterator on the menu, but first let’s see what an external iterator might look like in Ruby.
It is actually quite easy to construct Java-like external iterators in Ruby. A simple, if somewhat less than vitally needed, implementation of an iterator for Ruby arrays might look something like this:
class ArrayIterator
def initialize(array)
@array = array
@index = 0
end
def has_next?
@index < @array.length
end
def item
@array[@index]
end
def next_item
value = @array[@index]
@index += 1
value
end
end
ArrayIterator is a straightforward translation of a Java-style iterator into Ruby, albeit with the addition of item, a method that retrieves the current item (something that is oddly missing from the Java rendition). Here’s how we might use this new iterator:
array = ['red', 'green', 'blue']
i = ArrayIterator.new(array)
while i.has_next?
puts("item: #{i.next_item}")
end
Running this code will give us the output we expect:
item: red item: green item: blue
With just a few lines of code, our ArrayIterator gives us just about everything we need to iterate over any Ruby array. As a free bonus, Ruby’s flexible dynamic typing allows ArrayIterator to work on any aggregate class that has a length method and can be indexed by an integer. String is just such a class, and our ArrayIterator will work fine with strings:
i = ArrayIterator.new('abc')
while i.has_next?
puts("item: #{i.next_item.chr}")
end
Run the code above and you will see this output:
item: a item: b item: c
The only wrinkle in using ArrayIterator on strings is that string[n] returns the nth character in the string as a number, the character code. Hence we need the chr method in the example above.
Given how easy it was to build ArrayIterator, it is surprising that external iterators are so rare in Ruby. It turns out that Ruby has something better—and that this something better is based on our old friends the code block and the Proc object.