The Composite Design Pattern: Recursive Data Structures

Let's consider our model of a department directory. Fundamentally, we said that

A DeptDirectory is either:

• an empty directory, Empty, or
  
  
• a non-empty directory Cons, which has
  • a first, which is an Entry (the "first" entry in the directory), and
  • a rest, which is a DeptDirectory (the "rest" of the directory)
    

In OO design, the goal is to express the problem, not to contrive a process to get the right answer. Proper abstract modeling of the problem space will automatically lead to correct results.

Thus we create the following classes and relationships (DeptDirectory.java):

We clearly see the Union pattern here, as DeptDirectory is an abstraction of both Empty and Cons. But the unique characteristic is that Cons, a subclass of DeptDirectory, contains a reference to ("is composed with" --"has-a") its own superclass. That is, Cons is self-referential. This is also known as a recursive data structure.

DeptDirectory is an example of the classic list data structure, which enables us to represent arbitrarily large data sets.

This recursive data structure is so common, it can be expressed as the Composite Design Pattern.

Adding Behavior to a Recursive Data Structure

Now, our data structure so far is nice, but it would be even nicer if we could actually do something with it...

But since we are doing OOP, we must be driven by abstraction. The question to ask is: "Fundamentally, what can a DeptDirectory do?" or "Fundamentally, how does a DeptDirectory behave?"

One possible answer is: "One should be able to ask a DeptDirectory to find the address associated with a given name."

Note that this is quite different that asking "How can I get my data structure to do such and such?" If we model our system correctly, it will automatically and intrinsically do what we need it to do.

Our question and answer above have a couple of implications:

1. DeptDirectory has a method that takes a name and returns the address associated with that name. Let's call the method findAddress().
2. Empty and Cons behave differently when asked to find an address--thus findAddress() in DeptDirectory is abstract

What are the concrete behaviors of Empty and Cons?

• Empty: The given name cannot possibly be in an empty directory. The result must be some sort of error message such as "Name not found" or some sort of null result (e.g. return the Java constant, null).
• Cons: The desired name can be in one of only 2 possible places: either it is in first, which is an Entry object, or it is somewhere in rest, the rest of the directory. That is,
  • IF first contains a match for the given name, then we return the associated address
  • ELSE we look for the the given name in the rest of the directory, returning whatever that result may be. This is called delegating to the rest of the directory.It is no more that simply calling findAddress() on rest and returning the result.

This is OOP, so if that what we mean, then that's what we'll code (DeptDirectory2.java):

The actual code looks like this (the relevant code here is in red):

abstract class DeptDirectory {    
    public abstract String findAddress(String aName);
}

class Empty extends DeptDirectory {    
    public String findAddress(String aName) {
        return (null);
    }
}

class Cons extends DeptDirectory {
  Entry first;
  DeptDirectory rest;

  /* constructor */
  Cons(Entry f, DeptDirectory r) {
    this.first = f;
    this.rest = r;
  }

  /* accessors */
  Entry getFirst() { return this.first; }
  DeptDirectory getRest() { return this.rest; }	

  public String findAddress(String aName) {
    if(first.getName().equals(aName)) {
      return first.getAddress();
    }
    else {
      return rest.findAddress(aName);
    }
  }
}

The code is exactly what we said it had to be, before we wrote any code. No more, no less.

So how would you use/test this code? Try the following in DrJava (you will need to open Entry.java too):

Things to notice and think about:

• Each object does exactly what is abstractly defined to do--no more, no less.
• The findAddress behavior was coded for Empty and Cons separately. Yet, they are able to work together. Why?
• The usual check for the end of the list (directory) is completely missing. Why? Where did it go? Or was it never really necessary?
• Was the issue of how to search through a whole directory every directly addressed? Did it need to be?
• Does it matter how long the directory is? If not, why not?

"The objects are what they are and they do what they do.

The solution to the problem they are designed to solve is already there!"