Rockhopper Blog

Let’s take a look at a class for a Baseball player. In this example
I made it an abstract class but it could just as well have
been an interface for this discussion.
Show/Hide source

public abstract class Player {
	public abstract void swing();
}

And here is an implementation class.
Show/Hide source

public class Phillie extends Player {
	public void swing() {
		System.out.println("Strike out");
	}
}

And another implementation class.
Show/Hide source

public class Yankme extends Player {
	public void swing() {
		System.out.println("Receive check for $10000000000000000");
	}
}

When we test them out like this:

Show/Hide source

Phillie burrell = new Phillie();
burrell.swing();

Phillie howard = new Phillie();
howard.swing();

Yankme derelictCheater = new Yankme();
derelictCheater.swing();

Yankme hideousChopSuey = new Yankme();
hideousChopSuey.swing();

We get the following not surprising results:
Show/Hide source

Strike out
Strike out
Receive check for $10000000000000000
Receive check for $10000000000000000

Ignoring the fact that Howard led the league with a
gazillion strikeouts in 2007, what if we want to create
a Phillie object who doesn’t strike out? (Ok, we’re
leaving the real world now…).

Actually one way we could vary individual objects (players) is to
create an anonymous subclass. Here we override the normal
Phillie implementation for swing.
Show/Hide source

Phillie howard = new Phillie() {
	public void swing() {
		System.out.println("HR");
	}
};

That works. Every other Phillie will have the default behavior for
swing and Howard will put it in Ashburn Alley every time. Would
that were true in real life.

What if we wanted to keep the default behavior but do something
extra?

If you simply make a subclass of Player you get the behavior for the
new subclass. The good thing is the subclass is plug compatible with
Player so the client doesn’t have to know what the special behavior is.

But if you pass in any object that is a subclass of Player to
the new subclass’ constructor it can call that
player’s swing method and put special code either before or after
invocation. In essence we are decorating the original player object’s
method invocations. Here we have one abstract method the decorator
must implement (swing) but there could be more of course.

Here’s a jerk decorator who goes after the pitcher after he swings.

Show/Hide source

public class JerkPlayer extends Player {
	private Player player;

	public JerkPlayer(Player player) {
		this.player = player;
	}

	public void swing() {
		this.player.swing();
		System.out.println("Charge the mound");
	}
}

And this is how you use it.

Show/Hide source

// baseline. no change.
Yankme derelictCheater = new Yankme();
derelictCheater.swing();

// make this player a jerk above and beyond other Yankmes
Player p = new JerkPlayer(derelictCheater);
p.swing();

// he's still just a normal jerk Yankme
Yankme hideousChopSuey = new Yankme();
hideousChopSuey.swing();

Here when you tell derelictCheater to swing you get the default behavior.
But when you pass the derelictCheater object to the JerkPlayer and tell that
object to swing, you get the default and the new behavior. Creating
another Yankme and telling him to swing shows that only one jerk
plays for the Yankmes (here we leave real life).

Receive check for $10000000000000000
Receive check for $10000000000000000
Charge the mound
Receive check for $10000000000000000

We can copy the Jerk player and make a new class that looks almost
exactly like it. The only change is that the added behavior comes
before the original behavior.

Show/Hide source

public class NastyPlayer extends Player {
	private Player player;

	public NastyPlayer(Player player) {
		this.player = player;
	}

	public void swing() {
		System.out.println("Cuss");
		this.player.swing();
	}
}

And of course you can run it with the same example mutatis mutandis.
(s/Jerk/Nasty/g)

What is really cool though is this. You can decorate a decorator.
Show/Hide source

// make this player a jerk above and beyond other Yankmes
// and also make him nasty - above and beyond other Yankmes
Player p = new JerkPlayer(new NastyPlayer(derelictCheater));
p.swing();

Great. First Pets and now Baseball players. Give me something
I’d do in real life.

Ever see standard Java code like this?
Show/Hide source

PrintWriter w = null;
try {
	w = new PrintWriter(new BufferedWriter(new FileWriter("bach.txt")));

You must be hungry by now. Want a pizza? What do you want on it?
There are probably as many answers to that as there are
people who eat pizza. How would you model pizza as a class?

Show/Hide source

public class Pizza {
	public double getPrice() {
		return 6.95;
	}
}
public class PepperoniPizza extends Pizza {
	@Override
	public double getPrice() {
		return super.getPrice() + 1.5;
	}
}

and then a gazillion more subclasses for each topping.

How about combinations of toppings? AnchovyPizza extends what?
Pizza? PepperoniPizza? Well, sometimes you want just anchovies,
sometimes just pepperoni and sometimes both. Remember there is no
multiple implementation inheritance in Java (thank hobgoblins and pointed ears).

Here is a hint. Look at the client and tell me how you would implement your Pizzas.

Show/Hide source

Pizza p = new Pizza();
System.out.println(p.getPrice());

p = new Pepperoni(new Pizza());
System.out.println(p.getPrice());

p = new Pepperoni(new Anchovy(new Pizza()));
System.out.println(p.getPrice());

// for Californians
p = new Pepperoni(new PeanutButter(new Anchovy(new Pizza())));
System.out.println(p.getPrice());

These are some reasons why you would use the GoF Decorator Design Pattern.
Whenever you want to vary individual object’s behaviors with reusable and cascadable behavior
you can implement it like this.

Bookmark It

Hide Sites