Home

After years of coding, certain ways of organising your program will look more and more sensible. These patterns tend to give certain properties to your code – such as extensibility, ease of debugging and clarity. I will try to explain the distinct rationale behind each pattern.

Adapter

Perhaps it was a lack of planning, perhaps it was unforeseen circumstances. Whatever the cause, you have a ‘Client’ class which is expecting an object ‘Adaptee’ to implement a method ‘intendedMethod()’. Unfortunately, it just doesn’t implement it. ‘Adaptee’. It does however implement a similar method called ‘unusualMethod()’. The Adapter Pattern is here to join up the dots:

class Client {
    Client() {
        Target t = new Adapter();
        t.intendedMethod();
    }
}

interface Target{
    void intendedMethod();
}

// Special adapter class
class Adapter implements Target {
	Adaptee a;

	@Override
	void intendedMethod() {
		a.unusualMethod(false);
	}
}

// The odd class
class Adaptee {
	void unusualMethod(boolean debug) {}
}

So the Client has a Target which is implemented by the Adapter which has an Adaptee.

Bridge

There is a lot of confusion about the Bridge Pattern, probably because of its similarity to the Adapter Pattern. The idea is indeed similar but the structure is completely different. Here is a comparison to the four classes in the Adapter Pattern:

In the Adapter Pattern, the Client has a Target. In the Bridge Pattern, the Client extends the Target. In the Adapter Pattern, the Adapter has an Adaptee, in the Bridge Pattern, the Adaptee implements the Adapter. So you can see that the flexibility is reversed. The Adapter Pattern is designed to fix together two inflexible classes – the Client and the Adaptee. The Bridge Pattern says that the Target and the Adapter are inflexible and the other two classes need to implement their interfaces. Perhaps some UML will help:

blog20uml

or if you prefer, here is the code:

// Client can call currentAbstraction()
class Client extends Target{}

abstract class Target{
    Adapter adapter;

    void currentAbstraction() {
        adapter.fixedMethod();
    }
}

// This class is fixed, but the abstraction (Target) and
// the implementation (Adaptee) of it can change easily
interface Adapter {
	void fixedMethod();
}

class Adaptee {
	void fixedMethod() {}
}

These names don’t make a lot of sense for explaining the Bridge class on its own, but hopefully this is helpful as a comparison.

Composite

The point of the Composite Pattern is to allow a function to be performed easily on all objects in a tree. Both branch and leaf objects implement the same interface such that any action called on a branch is simply called on all children of that branch. Here is the code:

interface Shared {
    void act();
}

class Leaf implements Shared {
    @Override
    void act() {
        System.out.println("I'm a leaf");
    }
}

class Branch implements Shared {
    list<Leaf> children;

    Branch(list<Leaf> children) {
        this.children = children;
    }

    @Override
    void act() {
        for (Leaf l : children) {
            l.act();
        }
    }
}

Decorator

The Decorator Pattern is a way of adding functionality at runtime. A decorated object which implements MyInterface contains a component which also implements MyInterface. When a call is made to a MyInterface method, the same method is called in the component object.

class Client() {
    Client() {
        MyInterface i = new DecoratorA(new DecoratorB(new SimpleImplementation));
        i.method();
    }
}

interface MyInterface {
    void method();
}

class DecoratorA extends Decorator {
	method() {
		i.decorated();
		System.out.println("has been decorated");
	}
}

class DecoratorB extends Decorator {
	method() {
		i.decorated();
		System.out.println("has been decorated");
	}
}

class Decorator MyImplements Interface {
    Interface decorated;

    Decorator(Interface decorated) {
        this.decorated = decorated;
    }

    void method() {
        decorated.method();
    }
}

class SimpleImplementation {
	void method() {
		System.out.printl("basic");
	}
}
Advertisements

One thought on “Structural Patterns

  1. Pingback: Setting the Tone of Your Game | The CogMob Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s