Patterns Learned Fom `Iterator`

Pattern one:

When it comes to iterators, we can easily come up with that its use in abstracting the container and simplify the iteration operation like following example shows:

Iterator it = container.iterator()
while (it.hasNext()) {
    a = it.next();
    // do something
}

No matter which kind of container you are using (the container has to be iterable and as far as I know, the commonly-used container are all iterable.), you can re-use this piece of code without any change. And this may be extract as a method, like following:

public void doIterate(Iterator it) {
    while (it.hasNext()) {
        a = it.next();
        // do something
    }
}

You can even make it more general with another parameter:

public void doIterate(Iterator it, Function f) {
    while (it.hasNext()) {
        a = it.next();
        f(a);
    }
}

This kind of design pattern can isolate the module of handling elements in container, which may change a lot in the process of a project, from other business logic. So in this sense, it’s a really a time-saver pattern.

More about this pattern:

And there are some other operations  -- Aggregate operations -- which has the same functionality (isolation from other business logic). Here is some introduction about its support in Java and differences between iterators.

Pattern two:

Is that over? No, there is some lessons behind iterators that we normally not notice it.
Suppose we are implementing some container:

public class xxTree {
    Node root;
    // ...
    void addXXX(T t) {
    }
    T getXXX() {
    }
    // ...
}

And qw want to provide the interface related with iteration to make your container more powerful and easier to use.
So you may add a interface like the following:

    /**
    * return the next element in the tree
    */
    E getNext(){
    }

    /**
    * return whether there is next element in the tree
    */
    boolean hasNext() {
    }   

It seems fine to finish this job like this. But suppose you add some elements in it, begin iterating the tree then you add more elements to it. Because the structure of tree (you can take binary search tree as an example), you may have already iterate over the newly-added elements’ positions. In order to get those elements iterated, you have to re-initialize the state of internal position of something like root pointer.
So you may add one more method to do this:

    /**
    * re-initialize the state of iteration
    */
    void restart() {
    }

We almost finish the job. Again, Suppose we publish our code and some one want to use our code. But the problem is that he has to remember invoke restart() every time he want to re-iterate the tree. This bad design might always cause a bug if anyone accidentally forget to restart() before getNext().
The core of this problem is the order of those functions is so essential that it has to be that fixed order, otherwise, it may cause bug/exception/error. And we can’t depend on the user of our code to always remember that order so we have to fix it by some pattern.
To make sure already ‘restarted’ before getNext() and hasNext()? Right! Make getNext() and hasNext() to be the method of iterator rather than the container. Every time you want to iterate, you have to apply for a new iterator to iterate like following:

Iterator getIterator() {
    return new Iterator() {
        hasNext() {
            // ...
        }
        getNext() {
            // ...
        }
    };
}

But to notice that, most implementation of iterator just be the something like pointer and may be invalid after you modify the content of container. (here is an example in Java). Of course, in java modify it by iterator’s remove() is valid if it is supported.

More:

Here is a SO question about a design problem which have the same core with iterator problem.

Written with StackEdit.