Builder
1. Ideas
Builder is a creative design template that allows you to build complex objects step by step. Templates allow you to create different styles and avatars of an object using the same build code. 
2. Place the problem
Imagine a complex object that requires a lot of work, the step-by-step instantiation of multiple fields and nested objects. Such initialization code is usually buried inside a giant constructor with lots of parameters. Or even worse: scattered across the entire customer code. 
For example, think about how to create a House object. To build a simple house, you need to build four walls and one floor, install doors, install a pair of windows and build a roof. But what if you want a bigger, brighter home with a backyard and other amenities (like heating, plumbing and wiring)?
The simplest solution is to extend the base House class and create a set of subclasses to include all combinations of parameters. But in the end you will end up with a significant number of subclasses. Any new parameters, such as porch type, will require further development of this hierarchy.
There is another approach that does not involve breeding of subclasses. You could create a giant constructor right in the base House class with all the possible parameters to control the House object. While this approach actually eliminates the need for subclasses, it creates another problem.
In most cases, most parameters will go unused, making the constructor calls pretty bad. For example, only a small fraction of the houses have swimming pools, so the parameters associated with the pool will be useless nine times out of ten.
3. Solution
The Builder pattern suggests that you extract the object building code out of its own class and move it to separate objects called the generator.
Some construction steps may require different implementation when you need to build different product avatars. For example, the wall of a cabin may be built of wood, but the castle walls must be made of stone.
In this case, you could create several different builder classes that implement the same set of build steps, but in a different way. You can then use these builders during the build (i.e. a set of calls to build steps) to create different types of objects. 
For example, imagine one person builds everything from wood and glass, the second person builds everything out of stone and iron, and the third uses gold and diamonds. By calling the same group of steps, you get a regular house from the first builder, a small castle from the second, and a palace from the third. However, this will only work if the client code that calls the build steps can interact with the builders using the generic interface.
4. Instructions
You can go further and extract a series of calls to the builder steps you use to build the product into a separate class called director. The derector class determines the order in which the construction steps are performed, while the builder provides the implementation for those steps.
Having a director class in your program isn’t absolutely necessary. You can always call building steps in a specific order directly from the client code. However, the superintendent class can be a good place to put different construction processes in place so you can reuse them in your program.
In addition, the manager class completely hides the product’s structural details with the customer code. Customers just need to link the builder with the director, launch the project with the manager and get results from the builder.
5. Structure
6. Fake code
This example Builder template illustrates how you can reuse the same object building code when building different types of products, such as cars, and create corresponding manuals for them. 
A car is a complex object that can be constructed in hundreds of different ways. Instead of extending the Vehicle class with a giant constructor, we extract the vehicle assembly code into a separate vehicle building class. This class has a set of methods for configuring various car parts.
If the customer code needs to assemble a specially tuned, special model of the car, the code can work directly with the manufacturer. On the other hand, the customer can delegate the assembly to the manager class, which knows how to use the builder to create some of the most popular car models.
You might get shocked, but every car needs manuals (seriously, who read them?). The manual describes every feature of the car, so the details in the manual will be different on different models. That is why you should reuse existing construction processes for both real cars and their respective manuals. Of course, building a manual is not the same as building a car and that’s why we have to provide another class of builders that specialize in crafting manuals. This class implements the same construction methods as its car-making cousin, but instead of fabricating auto parts, it describes them. By passing these builders to the same Director object, we can build a car or a manual.
The last part is fetching the result object. A metal car and a paper notebook, although related, are very different things. We cannot put a method to fetch results in director without associating director with product specific classes. Consequently, we get construction results from the builder who did the work.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 | // Using the Builder pattern makes sense only when your products // are quite complex and require extensive configuration. The // following two products are related, although they don't have // a common interface. class Car is // A car can have a GPS, trip computer and some number of // seats. Different models of cars (sports car, SUV, // cabriolet) might have different features installed or // enabled. class Manual is // Each car should have a user manual that corresponds to // the car's configuration and describes all its features. // The builder interface specifies methods for creating the // different parts of the product objects. interface Builder is method reset() method setSeats(...) method setEngine(...) method setTripComputer(...) method setGPS(...) // The concrete builder classes follow the builder interface and // provide specific implementations of the building steps. Your // program may have several variations of builders, each // implemented differently. class CarBuilder implements Builder is private field car:Car // A fresh builder instance should contain a blank product // object which it uses in further assembly. constructor CarBuilder() is this.reset() // The reset method clears the object being built. method reset() is this.car = new Car() // All production steps work with the same product instance. method setSeats(...) is // Set the number of seats in the car. method setEngine(...) is // Install a given engine. method setTripComputer(...) is // Install a trip computer. method setGPS(...) is // Install a global positioning system. // Concrete builders are supposed to provide their own // methods for retrieving results. That's because various // types of builders may create entirely different products // that don't all follow the same interface. Therefore such // methods can't be declared in the builder interface (at // least not in a statically-typed programming language). // // Usually, after returning the end result to the client, a // builder instance is expected to be ready to start // producing another product. That's why it's a usual // practice to call the reset method at the end of the // `getProduct` method body. However, this behavior isn't // mandatory, and you can make your builder wait for an // explicit reset call from the client code before disposing // of the previous result. method getProduct():Car is product = this.car this.reset() return product // Unlike other creational patterns, builder lets you construct // products that don't follow the common interface. class CarManualBuilder implements Builder is private field manual:Manual constructor CarManualBuilder() is this.reset() method reset() is this.manual = new Manual() method setSeats(...) is // Document car seat features. method setEngine(...) is // Add engine instructions. method setTripComputer(...) is // Add trip computer instructions. method setGPS(...) is // Add GPS instructions. method getProduct():Manual is // Return the manual and reset the builder. // The director is only responsible for executing the building // steps in a particular sequence. It's helpful when producing // products according to a specific order or configuration. // Strictly speaking, the director class is optional, since the // client can control builders directly. class Director is private field builder:Builder // The director works with any builder instance that the // client code passes to it. This way, the client code may // alter the final type of the newly assembled product. method setBuilder(builder:Builder) this.builder = builder // The director can construct several product variations // using the same building steps. method constructSportsCar(builder: Builder) is builder.reset() builder.setSeats(2) builder.setEngine(new SportEngine()) builder.setTripComputer(true) builder.setGPS(true) method constructSUV(builder: Builder) is // ... // The client code creates a builder object, passes it to the // director and then initiates the construction process. The end // result is retrieved from the builder object. class Application is method makeCar() is director = new Director() CarBuilder builder = new CarBuilder() director.constructSportsCar(builder) Car car = builder.getProduct() CarManualBuilder builder = new CarManualBuilder() director.constructSportsCar(builder) // The final product is often retrieved from a builder // object since the director isn't aware of and not // dependent on concrete builders and products. Manual manual = builder.getProduct() |
7. Apply
- Make sure that you can clearly define the general build steps for building all available product demonstrations. Otherwise, you will not be able to continue implementing the template.
- Declare these steps in the base generator interface.
- Create a concrete builder class for each product rep and perform their construction steps.Don’t forget to implement a method to fetch the results of the build. The reason why this method cannot be declared inside the generator interface is because different builders can create products that do not have the same interface. Hence, you don’t know what the return type would be for such a method. However, if you are dealing with products from a hierarchy, then the fetch method can be safely added to the base interface.
- Think about creating a director class. It can include many different ways to build a product using the same constructor object.
- The client code creates both the generator and director objects. Before construction begins, the client must pass a builder object to the director. Typically, the client only does this once, through the parameters of the director’s constructor. Directors use the builder object in all other constructions. There is an alternative approach in which the builder is directed directly to the director’s construction method.
- Building results can only be obtained directly from the manager if all products follow the same interface. If not, the client fetches the results from the generator.
Reference link: https://refactoring.guru/design-patterns/builder