Builder Pattern: What is the purpose of the Director?

Question

First, I want to acknowledge that this question is very similar to this other one, but I wanted to ask with more specifics and hopefully garner higher quality answers.

Recently I followed a tutorial where the Builder pattern was implemented with a Director. I've streamlined the classes for demonstration purposes:

public class Director
{
    private readonly Builder _builder;

    public Director(Builder builder)
    {
        _builder = builder;
    }

    public void BuildProduct()
    {
        _builder.CreateProduct();
        _builder.BuildPart1();
        _builder.BuildPart2();
    }

    public Product GetProduct() => _builder.GetProduct();
}

public abstract class Builder
{
    protected Product Product;

    internal void CreateProduct()
    {
        Product = new Product();
    }

    internal Product GetProduct() => Product;

    internal abstract void BuildPart1();

    internal abstract void BuildPart2();
}

public class Thing1Builder : Builder
{
    internal override void BuildPart1() => Product.ThingStrings.Add("Thing-1 String-1");

    internal override void BuildPart2() => Product.ThingStrings.Add("Thing-1 String-2");
}

public class Thing2Builder : Builder
{
    internal override void BuildPart1() => Product.ThingStrings.Add("Thing-2 String-1");

    internal override void BuildPart2() => Product.ThingStrings.Add("Thing-2 String-2");
}

public class Product
{
    internal readonly ICollection<string> ThingStrings = new List<string>();

    public void Display()
    {
        foreach (string thingString in ThingStrings)
        {
            Console.WriteLine($"Thing string = {thingString}");
        }
    }
}

As I was following along with the tutorial, I couldn't help but wonder why we don't just put the Director's only meaningful method (the BuildProduct method) into the abstract base class of the builders. This still ensures all concrete builders get the same build template and does away with what seems like a useless layer. What advantages does the Director bring?

Here I have coded virtually the same thing, just without the director (Product class omitted because it did not change):

public abstract class BuilderWithoutDirector
{
    protected Product Product;

    public void CreateProduct()
    {
        Product = new Product();
        BuildPart1();
        BuildPart2();
    }

    public Product GetProduct() => Product;

    protected abstract void BuildPart1();

    protected abstract void BuildPart2();
}

public class Thing1BuilderWithoutDirector : BuilderWithoutDirector
{
    protected override void BuildPart1() => Product.ThingStrings.Add("Thing-1 String-1");

    protected override void BuildPart2() => Product.ThingStrings.Add("Thing-1 String-2");
}

public class Thing2BuilderWithoutDirector : BuilderWithoutDirector
{
    protected override void BuildPart1() => Product.ThingStrings.Add("Thing-2 String-1");

    protected override void BuildPart2() => Product.ThingStrings.Add("Thing-2 String-2");
}

Usages of these two examples look like this:

    private static void UseWithDirector()
    {
        var director = new Director(new Thing1Builder());
        director.BuildProduct();
        var thing1 = director.GetProduct();

        director = new Director(new Thing2Builder());
        director.BuildProduct();
        var thing2 = director.GetProduct();

        thing1.Display();
        thing2.Display();
    }

    private static void UseWithoutDirector()
    {
        var builder1 = new Thing1BuilderWithoutDirector();
        builder1.CreateProduct();
        var thing1 = builder1.GetProduct();

        var builder2 = new Thing2BuilderWithoutDirector();
        builder2.CreateProduct();
        var thing2 = builder2.GetProduct();

        thing1.Display();
        thing2.Display();
    }

These two methods output the same thing. I see a hint to an advantage with the Director version in that you create one director and reuse it with multiple builders which has a feeling of a top-level object that knows what's going on (please excuse the fuzzy logic there), but you still have to know about and create two different builders, so why not just use them directly?

Answer 1

Putting Director's job into Builder is a violation of Single Responsibility Principle because the Builder will have two responsibilities:

1. Responsibility of a Builder: It knows how to implement the BuildPart1 and BuildPart2 methods.
2. Responsibility of a Director: It knows which parts should be used in which order.

Indeed, when you, for example, change the order of the calls to BuildPart1 and BuildPart2 in the base class Builder, all of your concrete Thing*Builder(s) are affected unnecessarily (they have to be recompiled and redeployed).

Answer 2

You can use the Director to encapsulates code for construction and the steps that is required to contruct the object. In the following example you would have to have a RedCarBuilder and a GreenCarBuilder to do it with your base class. Best example I could find :)

The BuilderPattern tries to solve the problem where multiple constructors exists for an object with different purposes. Example, a constructor for creating a red car and another for creating a green car. But in code it is hard to see what the different constructors does.

public class Car
{
    public int Wheels { get; set; }

    public string Colour { get; set; }
}

public interface ICarBuilder
{
    void SetColour(string colour);
    void SetWheels(int count);

    Car GetResult();
}

public class CarBuilder : ICarBuilder
{
    private Car car;

    public CarBuilder()
    {
        this.car = new Car();
    }

    public void SetColour(string colour)
    {
        this.car.Colour = colour;
    }

    public void SetWheels(int count)
    {
        this.car.Wheels = count;
    }

    public Car GetResult() => car;
}

public class CarBuildDirector
{
    public Car ConstructRedCar()
    {
        CarBuilder builder = new CarBuilder();

        builder.SetColour("Red");
        builder.SetWheels(4);

        return builder.GetResult();
    }

    public Car ConstructGreenCar()
    {
        CarBuilder builder = new CarBuilder();

        builder.SetColour("Green");
        builder.SetWheels(4);

        return builder.GetResult();
    }
}

Answer 3

There is no requirement to have director while creating and using builder pattern.

In the example you suggested, when you do not use director, the builder classes look more like example of template method pattern.

Job of director here I think is to encapsulate logic of creating the final product by calling various methods of builder class.

Example of this you can find at https://sourcemaking.com/design_patterns/builder/java/1

But there is other version of buillder pattern suggested at http://www.javaworld.com/article/2074938/core-java/too-many-parameters-in-java-methods-part-3-builder-pattern.html

Thanks and regards, Chetan Ranpariya

Answer 4

This is an old question, but its also a topic I find myself persuading other developers about often enough that I think I want to submit a late answer anyhow. The accepted answer is correctly citing the Single Responsibility Principal. What I'd like to add is some more concrete thoughts about why that matters so much in the first place.

Director/Builder is a specialization of a more general pattern called Bridge, where you have combine implementation pairs from two different hierarchies that collaborate through a shared interface. M implementations of Type A and N implementations of Type B yields M * N unique combinations of behavior for the development and maintenance costs of M + N implementations.

Directors can represent different reasons or origins for wanting to construct an object. Builders can produce different end products. Having the ability to reuse every implementation of one hierarchy with any new implementation of the other is a huge boon to productivity!

Imagine I've developed a data transformation engine that needs an object graph constructed to describe each task it is given at runtime. I have a Domain Specific Language for my transformation engine that allows developers to create work for it from their IDE, and I have a websocket protocol that allows network services to submit units of work. I've also designed a relational database schema for supporting a central repository for hosting a cloud deployment of my transformation engine and triggering executions from a scheduler.

I can implement:

• A DSLDirector that parses my DSL and uses the parse tree to drive a Builder
• A WebSocketDirector that handles incoming websocket messages as direction for driving a Builder
• A RepositoryDirector that accepts some key identifiers, queries a database, and uses the returned rows to drive a Builder
• An ExportDirector that takes an instance of my language and describes itself to a Builder

On the Builder side, I might have:

• A DSLBuilder that turns a walk of my data transformation spec through the Builder API into a pre-formatted instance of its Domain Specific Language
• A WebsocketBuilder that turns a walk of my data transformation spec into a valid session of messages sent to a remote instance of my Websocket protocol
• A RepositoryBuilder that can formulate SQL queries to insert/update the persisted form of my data transformation language
• An ImportBuilder that can produce an in-memory object tree suitable for my transformation engine to execute.

I can use these in combinations to accomplish multiple related use cases much faster than if I wrote a standalone program for each:

• DSLDirector + WebSocketBuilder = Parse my IDE work and sent it to the repository service
• WebSocketDirector + RepositoryBuilder = Receive messages from my IDE and write the deployment content to the database tables.
• RepositoryDirector + WebSocketBuilder = Load my previous deployment from the database and wire it to a compute engine host
• WebSocketDirector + ImportBuilder = Create the executable model instance I previously saved, but in the address space of an execution service. Run it!

Later on in my product's lifetime, I might make some major changes to the exection model. I manage to express everything that was possible with the first engine's semantic, but the data model that is used to specify the same behavior is now shaped very very differently. What to do about our existing user base?

If the semantics of the old model are stil present in the new model, one way to deal with migrations is to provide a new builder that is able to use the previous interface to define its message passing contract, but implemets its equivalent meaning using my new object model.

Directory/Builder can be a huge boon to MxN integration use cases as well as to Migration/Upgrade pathways.

Anyhow, that's my two cents. :)