ActionScript 3 Design Patterns

We tend to think of the iterator pattern as simply a mechanism to access a collection of items in some sort of order. However, the motivation for the iterator pattern goes quite a bit beyond this everyday requirement. It is specifically designed to hide how you decide to structure the collection, but still provide a uniform interface to traverse and access its elements. We will look at a couple of examples where we change how the collection is implemented but keep the client oblivious to the change.

Let’s take a look at the class diagram to determine the relationships between the classes in the iterator pattern.

Gamma et. al. refer to a collection of items as an aggregate. A concrete aggregate implements the IIterableAggregate interface. The IIterableAggregate interface has to define at least one method - called createIterator in this case. Now this is significant because the interface doesn’t specify anything about what data structure should be used to implement your collection of items. The only thing that the client knows about the concrete aggregate is that the createIterator() method will return a concrete iterator.

IIterableAggregate.as

package
{
    public interface IIterableAggregate
    {
        function createIterator() : IIterator
    }
}

The concrete iterator is of type IIterator. The IIterator interface defines the basic methods to traverse and access elements of a collection ( I will use the more contemporary term “collection” to refer to a concrete aggregate - not to be confused with the Collection class in AS2 ).

IIterator.as

package
{
    public interface IIterator
    {
        function reset() : void
        function next() : *
        function hasNext() : Boolean
    }
}

The next() method returns the next element in the collection. Note that it doesn’t specify a return type, allowing the collection to contain any object. The hasNext() method returns a boolean value indicating whether the end of the collection has been reached. The reset() method simply re-positions the index to the starting element.

The two interfaces make the intent of the iterator pattern very clear. The interfaces don’t specify what form or structure  the collection takes. The collection can be an Array, Dictionary or a composite like an XML node. However, in combination they do two essential things that enables flexible implementation of collections. First, the Iterator interface provides a uniform way to access elements in a collection. This means that, no matter what structure you use, the collection will be traversed and elements accessed using the next(), hasNext(), and reset() methods. Second, it offloads the iteration and access methods to a separate ConcreteIterator class. Take a look back at the ConcreteAggregate class in the class diagram and note how the createIterator() method is implemented. The returned instance of ConcreteIterator has a parameterized constructor that takes in the instance of the ConcreteAggregate object as an argument. You can think of the iterator as a wrapper around the collection hiding its implementation details. This is what enables the iterator pattern to create extensible and reusable collections.

The Simple List

Let’s develop a minimalist example of an iterable aggregate. The simple list enables clients to create a list of items and access its elements sequentially.

SimpleList.as

package
{
    public class SimpleList implements IIterableAggregate
    {
        private var arr : Array;
 
        public function SimpleList( ... args )
        {
            arr = new Array();
            for ( var i:uint = 0; i < args.length; i++ )
            {
                arr[i] = args[i];
            }
        }
 
        public function createIterator() : IIterator
        {
            return new SimpleListIterator( arr );
        }
    }
}

The SimpleList class implements the IIterableAggregate interface. An Array is used to hold the collection by inserting all arguments passed to the constructor ( elements in the list ). The createIterator() method returns an iterator of type SimpleListIterator. Note how the Array that holds the collection is passed as an argument to the SimpleListIterator constructor.

The concrete aggregate and concrete iterator classes are interdependent as indicated in the class diagram. The dashed arrow from the ConcreteAggregate class to the ConcreteIterator class indicates a dependency; ConcreteAggregate depends on ConcreteIterator to implement the createIterator() method. Conversely, the solid arrow from the ConcreteIterator class to the ConcreteAggregate class indicates a one-way association where ConcreteIterator can access the internal properties of the ConcreteAggregate class.

Now all we have left to do is implement a client that instantiates a SimpleList and iterates through it.

Main.as

package
{
    import flash.display.Sprite;
 
    /**
    *   Main Class
    *   @ purpose:      Document class for movie
    */
    public class Main extends Sprite
    {
        public function Main()
        {
 
            // create an instance of a concrete aggregate
            var groceryList:SimpleList = new SimpleList( 'bread','butter','eggs' );
 
            // get an iterator for it
            var itr:IIterator = groceryList.createIterator()
 
            // iterate over the agregate
            while ( itr.hasNext() )
            {
                trace ( itr.next() );
            }
        }
    }
}

The client creates a grocery list, gets an iterator for it, and traces the list. Pretty simple example, but let’s see why the iterator is such an interesting pattern by changing how the collection is implemented.

Changing the implementation

Let’s say that we decide to implement the collection using an XML structure instead of an Array. Assume an hypothetical efficiency provided by the new implementation.

Modified SimpleList.as

package
{
    public class SimpleList implements IIterableAggregate
    {
        private var xml : XML;
 
        public function SimpleList( ... args )
        {
            xml = <list></list>;
            for ( var i:uint = 0; i < args.length; i++ )
            {
                xml.appendChild( { args[i] } );
            }
        }
 
        public function createIterator() : IIterator
        {
            return new XMLListIterator( xml );
        }
    }
}

A new type of iterator is needed now since the collection is implemented using a different data structure. An XMLListIterator class is implemented to iterate through an XML list.

XMLListIterator.as

package
{
    public class XMLListIterator implements IIterator
    {
        private var xml   : XML;
        private var index : Number;
 
        public function XMLListIterator( xmlObject : XML )
        {
            xml = xmlObject;
            reset();
        }
 
        public function reset() : void
        {
            index = -1;
        }
 
        public function next() : *
        {
            return xml.fooditem[ ++index ];
        }
 
        public function hasNext() : Boolean
        {
            return ( index < xml.children().length() - 1 );
        }
    }
}

Note that we completely changed the implementation of the concrete aggregate and utilized a new concrete iterator as well. However, the client code will still work as before without requiring any modification.

The iterator pattern allows flexible implementation of collections by not exposing the internal structure of the collection to the client. The iterator pattern is also a good example of how a well defined interface can hide implementation details but expose how modular code can be used.

Why not use for each…in or for…in?

What was that? Total waste of time did you say? Why not use the built-in iterator?

Pretty much all the modern languages have built-in iterators to traverse and access collections; and ActionScript 3 is no exception. This is testament to the utility of design patterns as many of the GoF patterns are natively implemented in AS3. The grocery list could have been created and accessed this way:

var groceryList:Array = new Array( 'bread','butter','eggs' );
 
for each (var item:* in groceryList)
{
    trace ( item );
}

The collection could have been implemented using any one of the native structures that are enumerable such as XML, Dictionary or even Object and easily accessed using the for each…in looping construct. From a purist’s standpoint, there is a downside as it requires the implementation of the collection to be exposed to the client - since the collection itself is an argument to for each…in.

So, would we ever need to implement an iterator pattern when we have these built-in constructs? Sure! there are collections that are not natively implemented in AS3 such as linked lists, trees, and custom structures that may be required for specific apps. There are also multiple ways of traversing collections. For example, there may be a need to traverse a collection randomly and not in any sequence. A tree structure can be traversed breadth-first as opposed to a depth-first to access its nodes. Implementing an iterator pattern will provide a uniform interface for each unique traversal method.

Look out for a future article on the iterator pattern where we will look at a more functional example that will utilize multiple traversal methods.

Source:

• iterator_example01
• iterator_example02

References:
Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.