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?
InstrumentDirector: OK, then fetch the parts.
InstrumentDirector: Great, now you can start the
PianoBuilder: The machine's broken.
InstrumentDirector: Well, can you fix it?
InstrumentDirector: OK, then fix it.
InstrumentDirector: Alright, now start production.
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.
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.
This work is licensed under a Creative Commons Attribution 3.0 Unported License.