Starbuzz Coffee has made a name for itself as the fastest growing coffee shop around. If you’ve seen one on your local corner, look across the street; you’ll see another one.

Because they’ve grown so quickly, they’re scrambling to update their ordering systems to match their beverage offerings.

When they first went into business they designed their classes like this...

In addition to your coffee, you can also ask for several condiments like steamed milk, soy, and mocha (otherwise known as chocolate), and have it all topped off with whipped milk. Starbuzz charges a bit for each of these, so they really need to get them built into their order system.

Here’s their first attempt...

Well, let’s give it a try. Let’s start with the Beverage base class and add instance variables to represent whether or not each beverage has milk, soy, mocha, and whip...

Now let’s add in the subclasses, one for each beverage on the menu:

public class Beverage {
  public double cost() {










  }
}

public class DarkRoast extends Beverage {

  public DarkRoast() {
    description = "Most Excellent Dark Roast";
  }

  public double cost() {




  }
}

Sharpen your pencil

What requirements or other factors might change that will impact this design?

Grasshopper is on to one of the most important design principles:

Come on in; we’re open. Feel free to extend our classes with any new behavior you like. If your needs or requirements change (and we know they will), just go ahead and make your own extensions.

Sorry, we’re closed. That’s right, we spent a lot of time getting this code correct and bug free, so we can’t let you alter the existing code. It must remain closed to modification. If you don’t like it, you can speak to the manager.

Our goal is to allow classes to be easily extended to incorporate new behavior without modifying existing code. What do we get if we accomplish this? Designs that are resilient to change and flexible enough to take on new functionality to meet changing requirements.

Okay, we’ve seen that representing our beverage plus condiment pricing scheme with inheritance has not worked out very well—we get class explosions and rigid designs, or we add functionality to the base class that isn’t appropriate for some of the subclasses.

So, here’s what we’ll do instead: we’ll start with a beverage and “decorate” it with the condiments at runtime. For example, if the customer wants a Dark Roast with Mocha and Whip, then we’ll:

Okay, but how do you “decorate” an object, and how does delegation come into this? A hint: think of decorator objects as “wrappers.” Let’s see how this works...

Let’s first take a look at the Decorator Pattern description:

While that describes the role of the Decorator Pattern, it doesn’t give us a lot of insight into how we’d apply the pattern to our own implementation. Let’s take a look at the class diagram, which is a little more revealing (on the next page we’ll look at the same structure applied to the beverage problem).

Okay, let’s work our Starbuzz beverages into this framework...

Some confusion over Inheritance versus Composition

Sue: What do you mean?

Mary: Look at the class diagram. The CondimentDecorator is extending the Beverage class. That’s inheritance, right?

Sue: True. I think the point is that it’s vital that the decorators have the same type as the objects they are going to decorate. So here we’re using inheritance to achieve the type matching, but we aren’t using inheritance to get behavior.

Mary: Okay, I can see how decorators need the same “interface” as the components they wrap because they need to stand in place of the component. But where does the behavior come in?

Sue: When we compose a decorator with a component, we are adding new behavior. We are acquiring new behavior not by inheriting it from a superclass, but by composing objects together.

Mary: Okay, so we’re subclassing the abstract class Beverage in order to have the correct type, not to inherit its behavior. The behavior comes in through the composition of decorators with the base components as well as other decorators.

Sue: That’s right.

Mary: Ooooh, I see. And because we are using object composition, we get a whole lot more flexibility about how to mix and match condiments and beverages. Very smooth.

Sue: Yes, if we rely on inheritance, then our behavior can only be determined statically at compile time. In other words, we get only whatever behavior the superclass gives us or that we override. With composition, we can mix and match decorators any way we like... at runtime.

Mary: And as I understand it, we can implement new decorators at any time to add new behavior. If we relied on inheritance, we’d have to go in and change existing code any time we wanted new behavior.

Sue: Exactly.

Mary: I just have one more question. If all we need to inherit is the type of the component, how come we didn’t use an interface instead of an abstract class for the Beverage class?

Sue: Well, remember, when we got this code, Starbuzz already had an abstract Beverage class. Traditionally the Decorator Pattern does specify an abstract component, but in Java, obviously, we could use an interface. But we always try to avoid altering existing code, so don’t “fix” it if the abstract class will work just fine.

Make a picture for what happens when the order is for a “double mocha soy latte with whip” beverage. Use the menu to get the correct prices, and draw your picture using the same format we used earlier (from a few pages back):

Sharpen your pencil

Draw your picture here.

It’s time to whip this design into some real code.

Let’s start with the Beverage class, which doesn’t need to change from Starbuzz’s original design. Let’s take a look:

Beverage is simple enough. Let’s implement the abstract class for the Condiments (Decorator) as well:

Now that we’ve got our base classes out of the way, let’s implement some beverages. We’ll start with Espresso. Remember, we need to set a description for the specific beverage and also implement the cost() method.

If you look back at the Decorator Pattern class diagram, you’ll see we’ve now written our abstract component (Beverage), we have our concrete components (HouseBlend), and we have our abstract decorator (CondimentDecorator). Now it’s time to implement the concrete decorators. Here’s Mocha:

On the next page we’ll actually instantiate the beverage and wrap it with all its condiments (decorators), but first...

Congratulations. It’s time to sit back, order a few coffees, and marvel at the flexible design you created with the Decorator Pattern.

Here’s some test code*to make orders:

Now, let’s get those orders in:

public abstract class Beverage {
      public enum Size { TALL, GRANDE, VENTI };
      Size size = Size.TALL;                   
      String description = "Unknown Beverage";
      public String getDescription() {
             return description;
      }
      public void setSize(Size size) {
             this.size = size;        
      }                               
      public Size getSize() {         
             return this.size;        
      }                               
      public abstract double cost();
}

The large number of classes in the java.io package is... overwhelming. Don’t feel alone if you said “whoa” the first (and second and third) time you looked at this API. But now that you know the Decorator Pattern, the I/O classes should make more sense since the java.io package is largely based on Decorator. Here’s a typical set of objects that use decorators to add functionality to reading data from a file:

BufferedInputStream and LineNumberInputStream both extend FilterInputStream, which acts as the abstract decorator class.

You can see that this isn’t so different from the Starbuzz design. You should now be in a good position to look over the java.io API docs and compose decorators on the various input streams.

You’ll see that the output streams have the same design. And you’ve probably already found that the Reader/Writer streams (for character-based data) closely mirror the design of the streams classes (with a few differences and inconsistencies, but close enough to figure out what’s going on).

Java I/O also points out one of the downsides of the Decorator Pattern: designs using this pattern often result in a large number of small classes that can be overwhelming to a developer trying to use the Decorator-based API. But now that you know how Decorator works, you can keep things in perspective and when you’re using someone else’s Decorator-heavy API, you can work through how their classes are organized so that you can easily use wrapping to get the behavior you’re after.

Okay, you know the Decorator Pattern, you’ve seen the I/O class diagram. You should be ready to write your own input decorator.

How about this: write a decorator that converts all uppercase characters to lowercase in the input stream. In other words, if we read in “I know the Decorator Pattern therefore I RULE!” then your decorator converts this to “i know the decorator pattern therefore i rule!”

Write some quick code to test the I/O decorator:

Give it a spin

Patterns Exposed

This week’s interview: Confessions of a Decorator

Head First: Welcome, Decorator Pattern. We’ve heard that you’ve been a bit down on yourself lately?

Decorator: Yes, I know the world sees me as the glamorous design pattern, but you know, I’ve got my share of problems just like everyone.

HeadFirst: Can you perhaps share some of your troubles with us?

Decorator: Sure. Well, you know I’ve got the power to add flexibility to designs, that much is for sure, but I also have a dark side. You see, I can sometimes add a lot of small classes to a design and this occasionally results in a design that’s less than straightforward for others to understand.

HeadFirst: Can you give us an example?

Decorator: Take the Java I/O libraries. These are notoriously difficult for people to understand at first. But if they just saw the classes as a set of wrappers around an InputStream, life would be much easier.

HeadFirst: That doesn’t sound so bad. You’re still a great pattern, and improving this is just a matter of public education, right?

Decorator: There’s more, I’m afraid. I’ve got typing problems: you see, people sometimes take a piece of client code that relies on specific types and introduce decorators without thinking through everything. Now, one great thing about me is that you can usually insert decorators transparently and the client never has to know it’s dealing with a decorator. But like I said, some code is dependent on specific types and when you start introducing decorators, boom! Bad things happen.

HeadFirst: Well, I think everyone understands that you have to be careful when inserting decorators. I don’t think this is a reason to be too down on yourself.

Decorator: I know, I try not to be. I also have the problem that introducing decorators can increase the complexity of the code needed to instantiate the component. Once you’ve got decorators, you’ve got to not only instantiate the component, but also wrap it with who knows how many decorators.

HeadFirst: I’ll be interviewing the Factory and Builder patterns next week—I hear they can be very helpful with this?

Decorator: That’s true; I should talk to those guys more often.

HeadFirst: Well, we all think you’re a great pattern for creating flexible designs and staying true to the Open-Closed Principle, so keep your chin up and think positively!

Decorator: I’ll do my best, thank you.

You’ve got another chapter under your belt and a new principle and pattern in the toolbox.

public class Beverage {

// declare instance variables for milkCost,
// soyCost, mochaCost, and whipCost, and
// getters and setters for milk, soy, mocha
// and whip.

public double cost() {

        float condimentCost = 0.0;
        if (hasMilk()) {
            condimentCost += milkCost;
        }
        if (hasSoy()) {
            condimentCost += soyCost;
        }
        if (hasMocha()) {
            condimentCost += mochaCost;
        }
        if (hasWhip()) {
            condimentCost += whipCost;
        }
        return condimentCost;
    }
}


public class DarkRoast extends Beverage {

    public DarkRoast() {
        description = "Most Excellent Dark Roast";
    }

    public double cost() {
        return 1.99 + super.cost();
    }
}

Sharpen your pencil Solution

New barista training

“double mocha soy latte with whip”

Sharpen your pencil Solution

Our friends at Starbuzz have introduced sizes to their menu. You can now order a coffee in tall, grande, and venti sizes (for us normal folk: small, medium, and large). Starbuzz saw this as an intrinsic part of the coffee class, so they’ve added two methods to the Beverage class: setSize() and getSize(). They’d also like for the condiments to be charged according to size, so for instance, Soy costs 10¢, 15¢, and 20¢, respectively, for tall, grande, and venti coffees.

How would you alter the decorator classes to handle this change in requirements? Here’s our solution.