Does the Builder pattern really need a Director?

Question

A Builder knows how to construct the various parts of an aggregate, while a Director knows the order in which they should be constructed. Wikipedia illustrates this pattern with a PizzaBuilder example:
http://en.wikipedia.org/wiki/Builder_pattern
I find it difficult to understand why one would not move the constructPizza() method (including its implementation) of Waiter (the Director) to PizzaBuilder (the abstract Builder), bypassing Waiter altogether:
PizzaBuilder hawaiianPizzaBuilder = new HawaiianPizzaBuilder();
hawaiianPizzaBuilder.constructPizza();
Pizza pizza = hawaiianPizzaBuilder.getPizza();Why is it so important to separate the how from the order? To me it looks like having a separate Director class makes things just more complicated without having real benefits.

Answer 1

Thank you for your reply. Are you suggesting that
real-world applications have several Directors that
differ in the order of construction? I just got
myself the GoF book and it speaks about just one
Director, which repeats the same construction
process, independent of the concrete builder passed
to it.If you look at the Consequences, list item 2 it states:
"..then different Directors can reuse it to build Product variants from the same set of parts. In the earlier RTF example, we could define a reader for a format other than RTF, say, an SGMLReader, and use the same TextConverters..."
Note that in the example the Reader is the Director and the TextConverter is the Builder.
The point of this pattern is to separate the code that knows what to do and the code that knows how to do it so that they can be combined indpendently.
Suppose you were writing a tool that could take XML or database rows and create a Swing GUI. Let's say you are also asked to take that XML and those database rows and create a web page.
If you combine the code that reads the input with the code that reads the output, you end up writing the xml reader twice, the database reader twice, the swing builder twice, and the web page builder twice. Then consider what happens if you need a third input format or more output formats.
I was thinking of using this pattern to create a
custom JTree in subsequent steps: 1) create the nodes
from a database, 2) create the tree model, 3) create
the tree. Right now everything happens in my JTree
constructor, which doesn't feel right since it's just
a GUI component. Would that be appropriate? I only
have one concrete builder now, so it seems a bit too
much.I would remove any knowledge of the database from your gui component. This doesn't require more code and it won't make things more complicated. I think you'll find that once you have done it, it will make things a lot easier to understand and work on. The idea that every Object should have a single responsibility is poorly defined but is, in my opinion, a very good way to think about your designs.