The Corporate Code

Today I’ve been looking at the composite pattern, in order to use it in the project I’m currently working on. The composite pattern is mainly designed to create a uniform way to approach similar objects. Let’s start with a nice quote from the GOF :

Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

What this basically means is that with the composite pattern we can create a tree-like structure of objects where every object can either be a leaf or a composite. This allows us to create a structure with an indefinite depth of objects. Let me just point out that there are 2 different implementations for this pattern but I will discuss both of them so you can decide which want you want to use.

Let’s start with the UML scheme for this pattern.

As you can see in the scheme we start with creating an interface for our composite pattern, which we will use in our client classes. By Using this interface we’re allowing ourselves to access our objects without actually knowing whether this object is a leaf or a composite in our structure. The basic idea is to add all generic methods to the interface so that you can access them in the client class by using the interface. The composite implementations should delegate all these generic methods to his child objects. This way we can traverse the tree and preform an operation on all components of our tree.

Let’s have a look at some code now. We will create a component pattern for shape objects. By using the composite pattern we can have drawings which have an infinite number of shapes. First of all we create an interface for our component pattern :


public interface Component {
public void draw();
public void growSize(int size);
public boolean isComposite();
}

As you can see we created an interface for our component pattern which defines the methods that apply to all components in our structure. Our next step would be to create the implementations of this interface, we’ll start with the leaf :

public class Circle Component {public void draw() {
// actual implementation of our draw
}
public void growSize(int size) {
// increase the diameter of our circle
}
public boolean isComposite() {
return false;
}

Next up is another implementation of the component, but this time it will be a composite :

public class Rectangle Component {
private List children = new ArrayList();public void draw() {
foreach(component comp : children) {
// actual implementation of our draw
}}
public void growSize(int size) {
foreach(component comp : children) {
// increase the diameter of our circle
}
}public List getChildren() {
return children;
}public void addChild(Component child) {
this.children.add(child);
}public void removeChild(Component child) {
this.children.remove(child);
}public boolean isComposite() {
return true;
}
}
Now, as I mentioned at the beginning of this post, there are 2 implementations of this pattern. As you might already noticed, we use a method called isComposite() to determine if this object is a leaf or a composite, because at some point in our client classes we will probably have to know whether or not the object has children in order to access them directly. This is where our implementations of the composite pattern differ. This implementation uses the isComposite() to determine if it’s a composite and then preforms a cast in order to use the getChildren() removeChild() and addChild(). The other implementation has those methods in the interface, so you will be able to call them at any component ( leaf and composite ), the main advantage is that we don’t have to do the the check and the cast, but on the other hand, we have to implement the methods in our leafs as-well, which will be methods that just throw an exception.

More information on this pattern can be found at javaworld or wikipedia.