GoF Builder Metaphor: Full Description

Problem

Motivation

Now, each of these Managers should be a specialist in the type of instrument they are building. The PianoManager must know how to arrange the keys, tune the strings, and so on. The DrumManager, likewise, must be able to create a drum from hoops, heads, and all the other stuff. So far, so good ... we're not going to find someone who's smart enough to do that, so we've created a different role for each manager.

But there's a problem. Knowing the details of building an instrument is not enough: there's a second kind of knowledge, higher-level knowledge aboute the overall process. For example, "retrieve parts, prepare machinery, start production, test results". Far from being about piano keys and drum hoops, we are talking here about a general product development process.

The solution here is to specialise further. So we create a third role: the InstrumentDirector. This role will free the instrument specialists to focus on what they're good at, while ensuring the overall process is consistent. The specialists are not managers under this arrangement, but builders, so we call them InstrumentBuilders.

The InstrumentDirector has a fixed process. The process may be quite sophisticated, but the fact is he needs to know nothing about pianos or drums. All he needs to know is how to delegate tasks to someone who knows the specifics of an instrument - an InstrumentBuilder.

So to make pianos and drums, we need a PianoBuilder and a DrumBuilder. Here is how the Director directs a Builder without knowing what kind of instrument will be built (along with some outrageous assumptions about the craft of instrument-building):

CEO (Client): InstrumentDirector, Go build me an instrument - your InstrumentBuilder will be this PianoBuilder.
InstrumentDirector: OK, no probs. Well, InstrumentBuilder, we have an instrument to build. OK, so first up, do we have the parts?
PianoBuilder: Yep.
InstrumentDirector: OK, then fetch the parts.
PianoBuilder: Done.
InstrumentDirector: Great, now you can start the
PianoBuilder: The machine's broken.
InstrumentDirector: Well, can you fix it?
PianoBuilder: Aha.
InstrumentDirector: OK, then fix it.
PianoBuilder: Fixed.
InstrumentDirector: Alright, now start production.
PianoBuilder: OK.
InstrumentDirector: Great, that's enough. Shut her down. Then test the result.
PianoBuilder: Great. She's finished and all tested.
InstrumentDirector: OK, we have the Instrument built by the InstrumentBuilder you sent me.
CEO (Client): Good work, thanks.

Comments on the Builder Pattern

Did you notice how the InstrumentDirector knows nothing about pianos? All he knows is how to deal with an InstrumentBuilder. The client could have provided a DrumBuilder and the result would have been a drum, built using the same set of steps - retrieve parts, prepare machinery, etc.

Actually, it wasn't just the set of steps. The InstrumentDirector also made a decision about what to do if the machine is broken. In a more complex environment, the directing logic will involve iteration (looping) and if-then decisions, as well as looking up data and perhaps responding to triggers such as external input.

This sort of logic is a specialisation in itself, and actually has very little to do with the particular Instrument being built. As long as Builders are trained so that they can be directed in a standard manner, the Director is able to ensure they do the building using a standard procedure.

The analogy to software should be clear. The pattern is used when a client needs to build different, related, classes using a consistent procedure. It requests an object from the Director, ensuring it has an appropriate Builder associated with it. The Director has the general algorithm for conducting the build, while the Builder actually carries out each phase on the specific product type is is capable of building.

When we say we should be able to direct the InstrumentBuilders in a standard manner, we are talking polymorphism. That is, the Builder classes must all comply to the same interface, so the Director can make the same method calls and have a consistent expectation about what will happen.

Related Patterns

• Strategy:
The Builder class is a kind of Strategy - we can plug in different Builders to receive different objects. The Director itself also encapsulates a Strategy which could be substituted (this is slightly inconsistent with the pattern as presented, which doesn't actually advise using a standard interface for the Director).
• Abstract Factory:
Another way to build classes. Builder is about choosing a single class from several related classes (usually, but not always, having a common parent class). Abstract Factory concerns the choice of an entire family of products.

This work is licensed under a Creative Commons Attribution 3.0 Unported License.