# Computer Science Design Patterns/Builder

The builder pattern is useful for avoiding a huge list of constructors for a class. Let's imagine a class that stores the mode of transport (of an employee for instance). Here is the constructor that takes a MetroLine object as a parameter:
* modeOfTransport(MetroLine)
Now we need a constructor for someone who uses the car, the bus or the train:
* new modeOfTransport(MetroLine)
* new modeOfTransport
* new modeOfTransport(BusLine)
* new modeOfTransport(Train)
For some of them, we need to indicate a travel allowance:
* new modeOfTransport(MetroLine)
* new modeOfTransport(MetroLine, Integer)
* new modeOfTransport
* new modeOfTransport(Integer)
* new modeOfTransport(BusLine)
* new modeOfTransport(BusLine, Integer)
* new modeOfTransport(Train)
* new modeOfTransport(Train, Integer)
We have employees who use several modes of transport to go to work. However, we realize that the list of constructors is now becoming a mess. Each new parameter leads to an exponential duplication of constructors. If some parameters have the same type, it becomes very confusing. A solution to this issue would be to first build a fake object and then fill it by calling methods on it:
* new modeOfTransport(MetroLine)
* modeOfTransport.setMetroLine(MetroLine)
* modeOfTransport.setCarTravel
* modeOfTransport.setBusLine(BusLine)
* modeOfTransport.setTrain(Train)
* modeOfTransport.setTravelAllowance(Integer)
The list of methods is no longer exponential but the state of the object may be inconsistent. A better solution would be to set all the parameters to an object of another class, a pre-constructor, and then pass this object to the constructor of ModeOfTransport:
* modeOfTransportPreConstructor.setMetroLine(MetroLine)
* modeOfTransportPreConstructor.setCarTravel
* modeOfTransportPreConstructor.setBusLine(BusLine)
* modeOfTransportPreConstructor.setTrain(Train)
* modeOfTransportPreConstructor.setTravelAllowance(Integer)
* new modeOfTransport(ModeOfTransportPreConstructor)
This solution is even better. We only have a single valid ModeOfTransport object. However, the ModeOfTransport constructor can be called with a half-filled pre-constructor. So the pre-constructor should be a builder and should have a method that returns the ModeOfTransport object. This method will only return an object if the builder has been correctly filled, otherwise it returns null:
* modeOfTransportBuilder.setMetroLine(MetroLine)
* modeOfTransportBuilder.setCarTravel
* modeOfTransportBuilder.setBusLine(BusLine)
* modeOfTransportBuilder.setTrain(Train)
* modeOfTransportBuilder.setTravelAllowance(Integer)
* modeOfTransport := modeOfTransportBuilder.getResult
So the solution is to use a builder class. Let's see the structure of the code in an UML class diagram:
* Builder: Abstract interface for creating objects (product).
* Concrete Builder: Provides implementation for Builder. It is an object able to construct other objects. Constructs and assembles parts to build the objects.
The builder pattern can be used for objects that contain flat data (html code, SQL query, X.509 certificate...), that is to say data that can't be easily edited. This type of data can not be edited step by step and must be edited all at once. The best way to construct such an object is to use a builder class.

## Examples

In Java, the StringBuffer and StringBuilder classes follow the builder design pattern. They are used to build String objects.

## Cost

You can easily decide to use it. At worst, the pattern is useless.

### Creation

Starting from a plain old class with a public constructor, implementing the design pattern is not very expensive. You can create the builder class alongside your code. Then you will have to remove the existing constructor calls to use the builder instead. The refactoring is hardly automatic.

### Maintenance

This design pattern has only small drawbacks. It may lead to small redundancies between the class and the builder structures but the both class have usually different structures. However, it is expensive to convert to an abstract factory.

### Removal

The refactoring is hardly automatic. It should be done manually.

## Advices

* Put the builder term in the name of the builder class to indicate the use of the pattern to the other developers.
* Build your builder class as a fluent interface. It would increase the pattern interest.
* If the target class contains flat data, your builder class can be constructed as a Composite that implements the Interpreter pattern.

## Implementations

Building a car.
It will produce:
Building a pizza.
The Director assembles a bicycle instance in the example above, delegating the construction to a separate builder object that has been given to the Director by the Client.
Another example:
This C++11 implementation is based on the pre C++98 implementation in the book.
The program output is like:
Another example:
output :