Builder Pattern : Why does the Director construct the object?

Question

I am learning the Builder Pattern

In the above link (Java example), I noticed that the Builder offers interface to construct multiple components. Along with invoking them, we call the getProduct() as well.

The point I don't understand is that why does the Director need to call all those component-construct methods one by one and get the result in the end.

     /** "Director" */
 class Waiter {
    private PizzaBuilder pizzaBuilder;


public void setPizzaBuilder(PizzaBuilder pb) { pizzaBuilder = pb; }
public Pizza getPizza() { return pizzaBuilder.getPizza(); }

public void constructPizza() {
   pizzaBuilder.createNewPizzaProduct(); 
   pizzaBuilder.buildDough(); // construct component 1
   pizzaBuilder.buildSauce(); // construct component 2
   pizzaBuilder.buildTopping();  // construct component 3
}

}

Why don't we include the code for constructing components 1, 2, 3 in the ConcreteBuilder class it self rather than in the Director, and in fact eliminate the Director layer.

I understand that the above approach might turn the Builder pattern into something else, but I don't get why the Director is doing the job step-by-step. What's the benefit? If there are multiple directors, there will be duplicate code, right? I might not be understanding the motive behind the execution of the Builder pattern...

UPDATE : Does the Builder pattern focus on offering customizable-component-selection while creating a larger complex object? Otherwise, as of now, I don't see the point in introducing an additional layer, the Director.

Even if that's the case, Decorator pattern might be a better idea to accomplish the same by dynamically customizing the components. Somewhere I'm missing the point behind the Builder.. :(

Answer 1

The purpose of the Director class is to encapsulate the algorithm for creating an object, i.e. separate the code for the construction logic from the code for the parts that actually make up the object. Without the Director class your Builder class would be bulkier and less modular, thus more difficult to maintain and less reusable.

The Wikipedia example you are referring to is rather simplistic. With complex objects, the construction mechanism is usually much more involved, and the Director does not necessarily call the Builder methods one-by-one and in the order they are defined. Consider, for instance, the Cake class: it may have parts ChocolateLayer, CreamLayer and Strawberry. The Builder would define the three methods for building these three parts in this particular order, however the constructCake() method in your Director class might look something like this:

public void constructCake() {
   CakeBuilder.createNewCakeProduct(); 
   CakeBuilder.buildChocolateLayer(); 
   CakeBuilder.buildCreamLayer(); 
   CakeBuilder.buildChocolateLayer(); // 2nd call of the same Builder method
   int totalStrawberries = 3 + new Random().nextInt(2);
   for (int i = 1; i <= totalStrawberries; i++) 
      CakeBuilder.buildStrawberry(); // put some strawberries on top
   // Please don't try this recipe at home! 
}

As for the differences between the Builder and the Decorator, you might check the Builder Vs Decorator pattern question.

Answer 2

The Director does not construct the object, the Builder does, and it's called the Product. The Director is there for one reason: so that the users of the class don't know anything about the steps required to construct the object. All this talk about just flattening it all into one method is like asking why can't we make a car into a unicycle. We could but a. it wouldn't be a car anymore, and b. it wouldn't be able to do all the things cars do that unicycles can't.

One of the best ways to look at Builder is as a fusion of Template Method and a Factory: we need an abstract construction process so we can support the creation of different Products, but the construction process involves many steps. The idea is that once you have the Director/Builder architecture in place, you can add new Builders easily by providing a new concrete implementation. It's like Template Method because the Builder can likewise ignore the details of the construction semantics, and just supply implementations of each required part of the construction (note also that some logic could end up in the abstract base of the Builder hierarchy, further expanding the amount of automatic functionality that the later extenders get for free).