--- title: "Builder" type: "design-pattern" slug: "builder" url: "http://localhost:3000/en/design-patterns/builder.md" category: "Creational Patterns" description: "Builder is a creational design pattern that lets you construct complex objects step by step. The pattern allows you to produce different types and representations of an object using the same construction code." languages: ["java", "csharp", "cpp", "go", "php", "python", "ruby", "rust", "swift", "typescript"] --- # Builder > Builder is a creational design pattern that lets you construct complex objects step by step. The pattern allows you to produce different types and representations of an object using the same construction code. ## Intent **Builder** is a creational design pattern that lets you construct complex objects step by step. The pattern allows you to produce different types and representations of an object using the same construction code. ## Problem Imagine a complex object that requires laborious, step-by-step initialization of many fields and nested objects. Such initialization code is usually buried inside a monstrous constructor with lots of parameters. Or even worse: scattered all over the client code. You might make the program too complex by creating a subclass for every possible configuration of an object. For example, let’s think about how to create a `House` object. To build a simple house, you need to construct four walls and a floor, install a door, fit a pair of windows, and build a roof. But what if you want a bigger, brighter house, with a backyard and other goodies (like a heating system, plumbing, and electrical wiring)? The simplest solution is to extend the base `House` class and create a set of subclasses to cover all combinations of the parameters. But eventually you’ll end up with a considerable number of subclasses. Any new parameter, such as the porch style, will require growing this hierarchy even more. There’s another approach that doesn’t involve breeding subclasses. You can create a giant constructor right in the base `House` class with all possible parameters that control the house object. While this approach indeed eliminates the need for subclasses, it creates another problem. The constructor with lots of parameters has its downside: not all the parameters are needed at all times. In most cases most of the parameters will be unused, making [the constructor calls pretty ugly](/smells/long-parameter-list). For instance, only a fraction of houses have swimming pools, so the parameters related to swimming pools will be useless nine times out of ten. ## Solution The Builder pattern suggests that you extract the object construction code out of its own class and move it to separate objects called _builders_. The Builder pattern lets you construct complex objects step by step. The Builder doesn’t allow other objects to access the product while it’s being built. The pattern organizes object construction into a set of steps (`buildWalls`, `buildDoor`, etc.). To create an object, you execute a series of these steps on a builder object. The important part is that you don’t need to call all of the steps. You can call only those steps that are necessary for producing a particular configuration of an object. Some of the construction steps might require different implementation when you need to build various representations of the product. For example, walls of a cabin may be built of wood, but the castle walls must be built with stone. In this case, you can create several different builder classes that implement the same set of building steps, but in a different manner. Then you can use these builders in the construction process (i.e., an ordered set of calls to the building steps) to produce different kinds of objects. Different builders execute the same task in various ways. For example, imagine a builder that builds everything from wood and glass, a second one that builds everything with stone and iron and a third one that uses gold and diamonds. By calling the same set 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 would only work if the client code that calls the building steps is able to interact with builders using a common interface. #### Director You can go further and extract a series of calls to the builder steps you use to construct a product into a separate class called _director_. The director class defines the order in which to execute the building steps, while the builder provides the implementation for those steps. The director knows which building steps to execute to get a working product. Having a director class in your program isn’t strictly necessary. You can always call the building steps in a specific order directly from the client code. However, the director class might be a good place to put various construction routines so you can reuse them across your program. In addition, the director class completely hides the details of product construction from the client code. The client only needs to associate a builder with a director, launch the construction with the director, and get the result from the builder. ## Structure 1. The **Builder** interface declares product construction steps that are common to all types of builders. 2. **Concrete Builders** provide different implementations of the construction steps. Concrete builders may produce products that don’t follow the common interface. 3. **Products** are resulting objects. Products constructed by different builders don’t have to belong to the same class hierarchy or interface. 4. The **Director** class defines the order in which to call construction steps, so you can create and reuse specific configurations of products. 5. The **Client** must associate one of the builder objects with the director. Usually, it’s done just once, via parameters of the director’s constructor. Then the director uses that builder object for all further construction. However, there’s an alternative approach for when the client passes the builder object to the production method of the director. In this case, you can use a different builder each time you produce something with the director. ## Pseudocode This example of the **Builder** pattern illustrates how you can reuse the same object construction code when building different types of products, such as cars, and create the corresponding manuals for them. The example of step-by-step construction of cars and the user guides that fit those car models. A car is a complex object that can be constructed in a hundred different ways. Instead of bloating the `Car` class with a huge constructor, we extracted the car assembly code into a separate car builder class. This class has a set of methods for configuring various parts of a car. If the client code needs to assemble a special, fine-tuned model of a car, it can work with the builder directly. On the other hand, the client can delegate the assembly to the director class, which knows how to use a builder to construct several of the most popular models of cars. You might be shocked, but every car needs a manual (seriously, who reads them?). The manual describes every feature of the car, so the details in the manuals vary across the different models. That’s why it makes sense to reuse an existing construction process for both real cars and their respective manuals. Of course, building a manual isn’t the same as building a car, and that’s why we must provide another builder class that specializes in composing manuals. This class implements the same building methods as its car-building sibling, but instead of crafting car parts, it describes them. By passing these builders to the same director object, we can construct either a car or a manual. The final part is fetching the resulting object. A metal car and a paper manual, although related, are still very different things. We can’t place a method for fetching results in the director without coupling the director to concrete product classes. Hence, we obtain the result of the construction from the builder which performed the job. // 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 // 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. // 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() ## Applicability Use the Builder pattern to get rid of a “telescoping constructor”. Say you have a constructor with ten optional parameters. Calling such a beast is very inconvenient; therefore, you overload the constructor and create several shorter versions with fewer parameters. These constructors still refer to the main one, passing some default values into any omitted parameters. class Pizza { Pizza(int size) { ... } Pizza(int size, boolean cheese) { ... } Pizza(int size, boolean cheese, boolean pepperoni) { ... } // ... Creating such a monster is only possible in languages that support method overloading, such as C# or Java. The Builder pattern lets you build objects step by step, using only those steps that you really need. After implementing the pattern, you don’t have to cram dozens of parameters into your constructors anymore. Use the Builder pattern when you want your code to be able to create different representations of some product (for example, stone and wooden houses). The Builder pattern can be applied when construction of various representations of the product involves similar steps that differ only in the details. The base builder interface defines all possible construction steps, and concrete builders implement these steps to construct particular representations of the product. Meanwhile, the director class guides the order of construction. Use the Builder to construct [Composite](/design-patterns/composite) trees or other complex objects. The Builder pattern lets you construct products step-by-step. You could defer execution of some steps without breaking the final product. You can even call steps recursively, which comes in handy when you need to build an object tree. A builder doesn’t expose the unfinished product while running construction steps. This prevents the client code from fetching an incomplete result. ## How to Implement 1. Make sure that you can clearly define the common construction steps for building all available product representations. Otherwise, you won’t be able to proceed with implementing the pattern. 2. Declare these steps in the base builder interface. 3. Create a concrete builder class for each of the product representations and implement their construction steps. Don’t forget about implementing a method for fetching the result of the construction. The reason why this method can’t be declared inside the builder interface is that various builders may construct products that don’t have a common interface. Therefore, you don’t know what would be the return type for such a method. However, if you’re dealing with products from a single hierarchy, the fetching method can be safely added to the base interface. 4. Think about creating a director class. It may encapsulate various ways to construct a product using the same builder object. 5. The client code creates both the builder and the director objects. Before construction starts, the client must pass a builder object to the director. Usually, the client does this only once, via parameters of the director’s class constructor. The director uses the builder object in all further construction. There’s an alternative approach, where the builder is passed to a specific product construction method of the director. 6. The construction result can be obtained directly from the director only if all products follow the same interface. Otherwise, the client should fetch the result from the builder. ## Pros * You can construct objects step-by-step, defer construction steps or run steps recursively. * You can reuse the same construction code when building various representations of products. * _Single Responsibility Principle_. You can isolate complex construction code from the business logic of the product. ## Cons * The overall complexity of the code increases since the pattern requires creating multiple new classes. ## Relations with Other Patterns * Many designs start by using [Factory Method](/design-patterns/factory-method) (less complicated and more customizable via subclasses) and evolve toward [Abstract Factory](/design-patterns/abstract-factory), [Prototype](/design-patterns/prototype), or [Builder](/design-patterns/builder) (more flexible, but more complicated). * [Builder](/design-patterns/builder) focuses on constructing complex objects step by step. [Abstract Factory](/design-patterns/abstract-factory) specializes in creating families of related objects. _Abstract Factory_ returns the product immediately, whereas _Builder_ lets you run some additional construction steps before fetching the product. * You can use [Builder](/design-patterns/builder) when creating complex [Composite](/design-patterns/composite) trees because you can program its construction steps to work recursively. * You can combine [Builder](/design-patterns/builder) with [Bridge](/design-patterns/bridge): the director class plays the role of the abstraction, while different builders act as implementations. * [Abstract Factories](/design-patterns/abstract-factory), [Builders](/design-patterns/builder) and [Prototypes](/design-patterns/prototype) can all be implemented as [Singletons](/design-patterns/singleton). ## Relations **Related patterns** - [Factory Method](/en/design-patterns/factory-method.md) - [Abstract Factory](/en/design-patterns/abstract-factory.md) - [Prototype](/en/design-patterns/prototype.md) - [Composite](/en/design-patterns/composite.md) - [Bridge](/en/design-patterns/bridge.md) - [Singleton](/en/design-patterns/singleton.md) ## Code Examples ### java ```java package refactoring_guru.builder.example.builders; import refactoring_guru.builder.example.cars.CarType; import refactoring_guru.builder.example.components.Engine; import refactoring_guru.builder.example.components.GPSNavigator; import refactoring_guru.builder.example.components.Transmission; import refactoring_guru.builder.example.components.TripComputer; /** * Builder interface defines all possible ways to configure a product. */ public interface Builder { void setCarType(CarType type); void setSeats(int seats); void setEngine(Engine engine); void setTransmission(Transmission transmission); void setTripComputer(TripComputer tripComputer); void setGPSNavigator(GPSNavigator gpsNavigator); } package refactoring_guru.builder.example.builders; import refactoring_guru.builder.example.cars.Car; import refactoring_guru.builder.example.cars.CarType; import refactoring_guru.builder.example.components.Engine; import refactoring_guru.builder.example.components.GPSNavigator; import refactoring_guru.builder.example.components.Transmission; import refactoring_guru.builder.example.components.TripComputer; /** * Concrete builders implement steps defined in the common interface. */ public class CarBuilder implements Builder { private CarType type; private int seats; private Engine engine; private Transmission transmission; private TripComputer tripComputer; private GPSNavigator gpsNavigator; @Override public void setCarType(CarType type) { this.type = type; } @Override public void setSeats(int seats) { this.seats = seats; } @Override public void setEngine(Engine engine) { this.engine = engine; } @Override public void setTransmission(Transmission transmission) { this.transmission = transmission; } @Override public void setTripComputer(TripComputer tripComputer) { this.tripComputer = tripComputer; } @Override public void setGPSNavigator(GPSNavigator gpsNavigator) { this.gpsNavigator = gpsNavigator; } public Car getResult() { return new Car(type, seats, engine, transmission, tripComputer, gpsNavigator); } } package refactoring_guru.builder.example.builders; import refactoring_guru.builder.example.cars.Manual; import refactoring_guru.builder.example.cars.CarType; import refactoring_guru.builder.example.components.Engine; import refactoring_guru.builder.example.components.GPSNavigator; import refactoring_guru.builder.example.components.Transmission; import refactoring_guru.builder.example.components.TripComputer; /** * Unlike other creational patterns, Builder can construct unrelated products, * which don't have the common interface. * * In this case we build a user manual for a car, using the same steps as we * built a car. This allows to produce manuals for specific car models, * configured with different features. */ public class CarManualBuilder implements Builder{ private CarType type; private int seats; private Engine engine; private Transmission transmission; private TripComputer tripComputer; private GPSNavigator gpsNavigator; @Override public void setCarType(CarType type) { this.type = type; } @Override public void setSeats(int seats) { this.seats = seats; } @Override public void setEngine(Engine engine) { this.engine = engine; } @Override public void setTransmission(Transmission transmission) { this.transmission = transmission; } @Override public void setTripComputer(TripComputer tripComputer) { this.tripComputer = tripComputer; } @Override public void setGPSNavigator(GPSNavigator gpsNavigator) { this.gpsNavigator = gpsNavigator; } public Manual getResult() { return new Manual(type, seats, engine, transmission, tripComputer, gpsNavigator); } } package refactoring_guru.builder.example.cars; import refactoring_guru.builder.example.components.Engine; import refactoring_guru.builder.example.components.GPSNavigator; import refactoring_guru.builder.example.components.Transmission; import refactoring_guru.builder.example.components.TripComputer; /** * Car is a product class. */ public class Car { private final CarType carType; private final int seats; private final Engine engine; private final Transmission transmission; private final TripComputer tripComputer; private final GPSNavigator gpsNavigator; private double fuel = 0; public Car(CarType carType, int seats, Engine engine, Transmission transmission, TripComputer tripComputer, GPSNavigator gpsNavigator) { this.carType = carType; this.seats = seats; this.engine = engine; this.transmission = transmission; this.tripComputer = tripComputer; if (this.tripComputer != null) { this.tripComputer.setCar(this); } this.gpsNavigator = gpsNavigator; } public CarType getCarType() { return carType; } public double getFuel() { return fuel; } public void setFuel(double fuel) { this.fuel = fuel; } public int getSeats() { return seats; } public Engine getEngine() { return engine; } public Transmission getTransmission() { return transmission; } public TripComputer getTripComputer() { return tripComputer; } public GPSNavigator getGpsNavigator() { return gpsNavigator; } } package refactoring_guru.builder.example.cars; import refactoring_guru.builder.example.components.Engine; import refactoring_guru.builder.example.components.GPSNavigator; import refactoring_guru.builder.example.components.Transmission; import refactoring_guru.builder.example.components.TripComputer; /** * Car manual is another product. Note that it does not have the same ancestor * as a Car. They are not related. */ public class Manual { private final CarType carType; private final int seats; private final Engine engine; private final Transmission transmission; private final TripComputer tripComputer; private final GPSNavigator gpsNavigator; public Manual(CarType carType, int seats, Engine engine, Transmission transmission, TripComputer tripComputer, GPSNavigator gpsNavigator) { this.carType = carType; this.seats = seats; this.engine = engine; this.transmission = transmission; this.tripComputer = tripComputer; this.gpsNavigator = gpsNavigator; } public String print() { String info = ""; info += "Type of car: " + carType + "\n"; info += "Count of seats: " + seats + "\n"; info += "Engine: volume - " + engine.getVolume() + "; mileage - " + engine.getMileage() + "\n"; info += "Transmission: " + transmission + "\n"; if (this.tripComputer != null) { info += "Trip Computer: Functional" + "\n"; } else { info += "Trip Computer: N/A" + "\n"; } if (this.gpsNavigator != null) { info += "GPS Navigator: Functional" + "\n"; } else { info += "GPS Navigator: N/A" + "\n"; } return info; } } package refactoring_guru.builder.example.cars; public enum CarType { CITY_CAR, SPORTS_CAR, SUV } package refactoring_guru.builder.example.components; /** * Just another feature of a car. */ public class Engine { private final double volume; private double mileage; private boolean started; public Engine(double volume, double mileage) { this.volume = volume; this.mileage = mileage; } public void on() { started = true; } public void off() { started = false; } public boolean isStarted() { return started; } public void go(double mileage) { if (started) { this.mileage += mileage; } else { System.err.println("Cannot go(), you must start engine first!"); } } public double getVolume() { return volume; } public double getMileage() { return mileage; } } package refactoring_guru.builder.example.components; /** * Just another feature of a car. */ public class GPSNavigator { private String route; public GPSNavigator() { this.route = "221b, Baker Street, London to Scotland Yard, 8-10 Broadway, London"; } public GPSNavigator(String manualRoute) { this.route = manualRoute; } public String getRoute() { return route; } } package refactoring_guru.builder.example.components; /** * Just another feature of a car. */ public enum Transmission { SINGLE_SPEED, MANUAL, AUTOMATIC, SEMI_AUTOMATIC } package refactoring_guru.builder.example.components; import refactoring_guru.builder.example.cars.Car; /** * Just another feature of a car. */ public class TripComputer { private Car car; public void setCar(Car car) { this.car = car; } public void showFuelLevel() { System.out.println("Fuel level: " + car.getFuel()); } public void showStatus() { if (this.car.getEngine().isStarted()) { System.out.println("Car is started"); } else { System.out.println("Car isn't started"); } } } package refactoring_guru.builder.example.director; import refactoring_guru.builder.example.builders.Builder; import refactoring_guru.builder.example.cars.CarType; import refactoring_guru.builder.example.components.Engine; import refactoring_guru.builder.example.components.GPSNavigator; import refactoring_guru.builder.example.components.Transmission; import refactoring_guru.builder.example.components.TripComputer; /** * Director defines the order of building steps. It works with a builder object * through common Builder interface. Therefore it may not know what product is * being built. */ public class Director { public void constructSportsCar(Builder builder) { builder.setCarType(CarType.SPORTS_CAR); builder.setSeats(2); builder.setEngine(new Engine(3.0, 0)); builder.setTransmission(Transmission.SEMI_AUTOMATIC); builder.setTripComputer(new TripComputer()); builder.setGPSNavigator(new GPSNavigator()); } public void constructCityCar(Builder builder) { builder.setCarType(CarType.CITY_CAR); builder.setSeats(2); builder.setEngine(new Engine(1.2, 0)); builder.setTransmission(Transmission.AUTOMATIC); builder.setTripComputer(new TripComputer()); builder.setGPSNavigator(new GPSNavigator()); } public void constructSUV(Builder builder) { builder.setCarType(CarType.SUV); builder.setSeats(4); builder.setEngine(new Engine(2.5, 0)); builder.setTransmission(Transmission.MANUAL); builder.setGPSNavigator(new GPSNavigator()); } } package refactoring_guru.builder.example; import refactoring_guru.builder.example.builders.CarBuilder; import refactoring_guru.builder.example.builders.CarManualBuilder; import refactoring_guru.builder.example.cars.Car; import refactoring_guru.builder.example.cars.Manual; import refactoring_guru.builder.example.director.Director; /** * Demo class. Everything comes together here. */ public class Demo { public static void main(String[] args) { Director director = new Director(); // Director gets the concrete builder object from the client // (application code). That's because application knows better which // builder to use to get a specific product. CarBuilder builder = new CarBuilder(); director.constructSportsCar(builder); // The final product is often retrieved from a builder object, since // Director is not aware and not dependent on concrete builders and // products. Car car = builder.getResult(); System.out.println("Car built:\n" + car.getCarType()); CarManualBuilder manualBuilder = new CarManualBuilder(); // Director may know several building recipes. director.constructSportsCar(manualBuilder); Manual carManual = manualBuilder.getResult(); System.out.println("\nCar manual built:\n" + carManual.print()); } } Car built: SPORTS_CAR Car manual built: Type of car: SPORTS_CAR Count of seats: 2 Engine: volume - 3.0; mileage - 0.0 Transmission: SEMI_AUTOMATIC Trip Computer: Functional GPS Navigator: Functional ``` ### csharp ```csharp using System; using System.Collections.Generic; namespace RefactoringGuru.DesignPatterns.Builder.Conceptual { // The Builder interface specifies methods for creating the different parts // of the Product objects. public interface IBuilder { void BuildPartA(); void BuildPartB(); void BuildPartC(); } // The Concrete Builder classes follow the Builder interface and provide // specific implementations of the building steps. Your program may have // several variations of Builders, implemented differently. public class ConcreteBuilder : IBuilder { private Product _product = new Product(); // A fresh builder instance should contain a blank product object, which // is used in further assembly. public ConcreteBuilder() { this.Reset(); } public void Reset() { this._product = new Product(); } // All production steps work with the same product instance. public void BuildPartA() { this._product.Add("PartA1"); } public void BuildPartB() { this._product.Add("PartB1"); } public void BuildPartC() { this._product.Add("PartC1"); } // 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 follow the same // interface. Therefore, such methods cannot be declared in the base // Builder interface (at least 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 is not // mandatory, and you can make your builders wait for an explicit reset // call from the client code before disposing of the previous result. public Product GetProduct() { Product result = this._product; this.Reset(); return result; } } // It makes sense to use the Builder pattern only when your products are // quite complex and require extensive configuration. // // Unlike in other creational patterns, different concrete builders can // produce unrelated products. In other words, results of various builders // may not always follow the same interface. public class Product { private List _parts = new List(); public void Add(string part) { this._parts.Add(part); } public string ListParts() { string str = string.Empty; for (int i = 0; i < this._parts.Count; i++) { str += this._parts[i] + ", "; } str = str.Remove(str.Length - 2); // removing last ",c" return "Product parts: " + str + "\n"; } } // The Director is only responsible for executing the building steps in a // particular sequence. It is 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. public class Director { private IBuilder _builder; public IBuilder Builder { set { _builder = value; } } // The Director can construct several product variations using the same // building steps. public void BuildMinimalViableProduct() { this._builder.BuildPartA(); } public void BuildFullFeaturedProduct() { this._builder.BuildPartA(); this._builder.BuildPartB(); this._builder.BuildPartC(); } } class Program { static void Main(string[] args) { // 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. var director = new Director(); var builder = new ConcreteBuilder(); director.Builder = builder; Console.WriteLine("Standard basic product:"); director.BuildMinimalViableProduct(); Console.WriteLine(builder.GetProduct().ListParts()); Console.WriteLine("Standard full featured product:"); director.BuildFullFeaturedProduct(); Console.WriteLine(builder.GetProduct().ListParts()); // Remember, the Builder pattern can be used without a Director // class. Console.WriteLine("Custom product:"); builder.BuildPartA(); builder.BuildPartC(); Console.Write(builder.GetProduct().ListParts()); } } } Standard basic product: Product parts: PartA1 Standard full featured product: Product parts: PartA1, PartB1, PartC1 Custom product: Product parts: PartA1, PartC1 ``` ### cpp ```cpp /** * It makes sense to use the Builder pattern only when your products are quite * complex and require extensive configuration. * * Unlike in other creational patterns, different concrete builders can produce * unrelated products. In other words, results of various builders may not * always follow the same interface. */ class Product1{ public: std::vector parts_; void ListParts()const{ std::cout << "Product parts: "; for (size_t i=0;iReset(); } ~ConcreteBuilder1(){ delete product; } void Reset(){ this->product= new Product1(); } /** * All production steps work with the same product instance. */ void ProducePartA()const override{ this->product->parts_.push_back("PartA1"); } void ProducePartB()const override{ this->product->parts_.push_back("PartB1"); } void ProducePartC()const override{ this->product->parts_.push_back("PartC1"); } /** * 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 follow the same interface. * Therefore, such methods cannot be declared in the base Builder interface * (at least in a statically typed programming language). Note that PHP is a * dynamically typed language and this method CAN be in the base interface. * However, we won't declare it there for the sake of clarity. * * 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 is not mandatory, and * you can make your builders wait for an explicit reset call from the * client code before disposing of the previous result. */ /** * Please be careful here with the memory ownership. Once you call * GetProduct the user of this function is responsable to release this * memory. Here could be a better option to use smart pointers to avoid * memory leaks */ Product1* GetProduct() { Product1* result= this->product; this->Reset(); return result; } }; /** * The Director is only responsible for executing the building steps in a * particular sequence. It is 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{ /** * @var Builder */ private: 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. */ public: void set_builder(Builder* builder){ this->builder=builder; } /** * The Director can construct several product variations using the same * building steps. */ void BuildMinimalViableProduct(){ this->builder->ProducePartA(); } void BuildFullFeaturedProduct(){ this->builder->ProducePartA(); this->builder->ProducePartB(); this->builder->ProducePartC(); } }; /** * 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. */ /** * I used raw pointers for simplicity however you may prefer to use smart * pointers here */ void ClientCode(Director& director) { ConcreteBuilder1* builder = new ConcreteBuilder1(); director.set_builder(builder); std::cout << "Standard basic product:\n"; director.BuildMinimalViableProduct(); Product1* p= builder->GetProduct(); p->ListParts(); delete p; std::cout << "Standard full featured product:\n"; director.BuildFullFeaturedProduct(); p= builder->GetProduct(); p->ListParts(); delete p; // Remember, the Builder pattern can be used without a Director class. std::cout << "Custom product:\n"; builder->ProducePartA(); builder->ProducePartC(); p=builder->GetProduct(); p->ListParts(); delete p; delete builder; } int main(){ Director* director= new Director(); ClientCode(*director); delete director; return 0; } Standard basic product: Product parts: PartA1 Standard full featured product: Product parts: PartA1, PartB1, PartC1 Custom product: Product parts: PartA1, PartC1 ``` ### go ```go package main type IBuilder interface { setWindowType() setDoorType() setNumFloor() getHouse() House } func getBuilder(builderType string) IBuilder { if builderType == "normal" { return newNormalBuilder() } if builderType == "igloo" { return newIglooBuilder() } return nil } package main type NormalBuilder struct { windowType string doorType string floor int } func newNormalBuilder() *NormalBuilder { return &NormalBuilder{} } func (b *NormalBuilder) setWindowType() { b.windowType = "Wooden Window" } func (b *NormalBuilder) setDoorType() { b.doorType = "Wooden Door" } func (b *NormalBuilder) setNumFloor() { b.floor = 2 } func (b *NormalBuilder) getHouse() House { return House{ doorType: b.doorType, windowType: b.windowType, floor: b.floor, } } package main type IglooBuilder struct { windowType string doorType string floor int } func newIglooBuilder() *IglooBuilder { return &IglooBuilder{} } func (b *IglooBuilder) setWindowType() { b.windowType = "Snow Window" } func (b *IglooBuilder) setDoorType() { b.doorType = "Snow Door" } func (b *IglooBuilder) setNumFloor() { b.floor = 1 } func (b *IglooBuilder) getHouse() House { return House{ doorType: b.doorType, windowType: b.windowType, floor: b.floor, } } package main type House struct { windowType string doorType string floor int } package main type Director struct { builder IBuilder } func newDirector(b IBuilder) *Director { return &Director{ builder: b, } } func (d *Director) setBuilder(b IBuilder) { d.builder = b } func (d *Director) buildHouse() House { d.builder.setDoorType() d.builder.setWindowType() d.builder.setNumFloor() return d.builder.getHouse() } package main import "fmt" func main() { normalBuilder := getBuilder("normal") iglooBuilder := getBuilder("igloo") director := newDirector(normalBuilder) normalHouse := director.buildHouse() fmt.Printf("Normal House Door Type: %s\n", normalHouse.doorType) fmt.Printf("Normal House Window Type: %s\n", normalHouse.windowType) fmt.Printf("Normal House Num Floor: %d\n", normalHouse.floor) director.setBuilder(iglooBuilder) iglooHouse := director.buildHouse() fmt.Printf("\nIgloo House Door Type: %s\n", iglooHouse.doorType) fmt.Printf("Igloo House Window Type: %s\n", iglooHouse.windowType) fmt.Printf("Igloo House Num Floor: %d\n", iglooHouse.floor) } Normal House Door Type: Wooden Door Normal House Window Type: Wooden Window Normal House Num Floor: 2 Igloo House Door Type: Snow Door Igloo House Window Type: Snow Window Igloo House Num Floor: 1 ``` ### php ```php reset(); } public function reset(): void { $this->product = new Product1(); } /** * All production steps work with the same product instance. */ public function producePartA(): void { $this->product->parts[] = "PartA1"; } public function producePartB(): void { $this->product->parts[] = "PartB1"; } public function producePartC(): void { $this->product->parts[] = "PartC1"; } /** * 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 follow the same interface. * Therefore, such methods cannot be declared in the base Builder interface * (at least in a statically typed programming language). Note that PHP is a * dynamically typed language and this method CAN be in the base interface. * However, we won't declare it there for the sake of clarity. * * 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 is not mandatory, and * you can make your builders wait for an explicit reset call from the * client code before disposing of the previous result. */ public function getProduct(): Product1 { $result = $this->product; $this->reset(); return $result; } } /** * It makes sense to use the Builder pattern only when your products are quite * complex and require extensive configuration. * * Unlike in other creational patterns, different concrete builders can produce * unrelated products. In other words, results of various builders may not * always follow the same interface. */ class Product1 { public $parts = []; public function listParts(): void { echo "Product parts: " . implode(', ', $this->parts) . "\n\n"; } } /** * The Director is only responsible for executing the building steps in a * particular sequence. It is 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 { /** * @var Builder */ private $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. */ public function setBuilder(Builder $builder): void { $this->builder = $builder; } /** * The Director can construct several product variations using the same * building steps. */ public function buildMinimalViableProduct(): void { $this->builder->producePartA(); } public function buildFullFeaturedProduct(): void { $this->builder->producePartA(); $this->builder->producePartB(); $this->builder->producePartC(); } } /** * 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. */ function clientCode(Director $director) { $builder = new ConcreteBuilder1(); $director->setBuilder($builder); echo "Standard basic product:\n"; $director->buildMinimalViableProduct(); $builder->getProduct()->listParts(); echo "Standard full featured product:\n"; $director->buildFullFeaturedProduct(); $builder->getProduct()->listParts(); // Remember, the Builder pattern can be used without a Director class. echo "Custom product:\n"; $builder->producePartA(); $builder->producePartC(); $builder->getProduct()->listParts(); } $director = new Director(); clientCode($director); Standard basic product: Product parts: PartA1 Standard full featured product: Product parts: PartA1, PartB1, PartC1 Custom product: Product parts: PartA1, PartC1 select(...)->where(...) */ interface SQLQueryBuilder { public function select(string $table, array $fields): SQLQueryBuilder; public function where(string $field, string $value, string $operator = '='): SQLQueryBuilder; public function limit(int $start, int $offset): SQLQueryBuilder; // +100 other SQL syntax methods... public function getSQL(): string; } /** * Each Concrete Builder corresponds to a specific SQL dialect and may implement * the builder steps a little bit differently from the others. * * This Concrete Builder can build SQL queries compatible with MySQL. */ class MysqlQueryBuilder implements SQLQueryBuilder { protected $query; protected function reset(): void { $this->query = new \stdClass(); } /** * Build a base SELECT query. */ public function select(string $table, array $fields): SQLQueryBuilder { $this->reset(); $this->query->base = "SELECT " . implode(", ", $fields) . " FROM " . $table; $this->query->type = 'select'; return $this; } /** * Add a WHERE condition. */ public function where(string $field, string $value, string $operator = '='): SQLQueryBuilder { if (!in_array($this->query->type, ['select', 'update', 'delete'])) { throw new \Exception("WHERE can only be added to SELECT, UPDATE OR DELETE"); } $this->query->where[] = "$field $operator '$value'"; return $this; } /** * Add a LIMIT constraint. */ public function limit(int $start, int $offset): SQLQueryBuilder { if (!in_array($this->query->type, ['select'])) { throw new \Exception("LIMIT can only be added to SELECT"); } $this->query->limit = " LIMIT " . $start . ", " . $offset; return $this; } /** * Get the final query string. */ public function getSQL(): string { $query = $this->query; $sql = $query->base; if (!empty($query->where)) { $sql .= " WHERE " . implode(' AND ', $query->where); } if (isset($query->limit)) { $sql .= $query->limit; } $sql .= ";"; return $sql; } } /** * This Concrete Builder is compatible with PostgreSQL. While Postgres is very * similar to Mysql, it still has several differences. To reuse the common code, * we extend it from the MySQL builder, while overriding some of the building * steps. */ class PostgresQueryBuilder extends MysqlQueryBuilder { /** * Among other things, PostgreSQL has slightly different LIMIT syntax. */ public function limit(int $start, int $offset): SQLQueryBuilder { parent::limit($start, $offset); $this->query->limit = " LIMIT " . $start . " OFFSET " . $offset; return $this; } // + tons of other overrides... } /** * Note that the client code uses the builder object directly. A designated * Director class is not necessary in this case, because the client code needs * different queries almost every time, so the sequence of the construction * steps cannot be easily reused. * * Since all our query builders create products of the same type (which is a * string), we can interact with all builders using their common interface. * Later, if we implement a new Builder class, we will be able to pass its * instance to the existing client code without breaking it thanks to the * SQLQueryBuilder interface. */ function clientCode(SQLQueryBuilder $queryBuilder) { // ... $query = $queryBuilder ->select("users", ["name", "email", "password"]) ->where("age", 18, ">") ->where("age", 30, "<") ->limit(10, 20) ->getSQL(); echo $query; // ... } /** * The application selects the proper query builder type depending on a current * configuration or the environment settings. */ // if ($_ENV['database_type'] == 'postgres') { // $builder = new PostgresQueryBuilder(); } else { // $builder = new MysqlQueryBuilder(); } // // clientCode($builder); echo "Testing MySQL query builder:\n"; clientCode(new MysqlQueryBuilder()); echo "\n\n"; echo "Testing PostgresSQL query builder:\n"; clientCode(new PostgresQueryBuilder()); Testing MySQL query builder: SELECT name, email, password FROM users WHERE age > '18' AND age < '30' LIMIT 10, 20; Testing PostgresSQL query builder: SELECT name, email, password FROM users WHERE age > '18' AND age < '30' LIMIT 10 OFFSET 20; ``` ### python ```python from __future__ import annotations from abc import ABC, abstractmethod from typing import Any class Builder(ABC): """ The Builder interface specifies methods for creating the different parts of the Product objects. """ @property @abstractmethod def product(self) -> None: pass @abstractmethod def produce_part_a(self) -> None: pass @abstractmethod def produce_part_b(self) -> None: pass @abstractmethod def produce_part_c(self) -> None: pass class ConcreteBuilder1(Builder): """ The Concrete Builder classes follow the Builder interface and provide specific implementations of the building steps. Your program may have several variations of Builders, implemented differently. """ def __init__(self) -> None: """ A fresh builder instance should contain a blank product object, which is used in further assembly. """ self.reset() def reset(self) -> None: self._product = Product1() @property def product(self) -> Product1: """ 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 follow the same interface. Therefore, such methods cannot be declared in the base Builder interface (at least 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 is not mandatory, and you can make your builders wait for an explicit reset call from the client code before disposing of the previous result. """ product = self._product self.reset() return product def produce_part_a(self) -> None: self._product.add("PartA1") def produce_part_b(self) -> None: self._product.add("PartB1") def produce_part_c(self) -> None: self._product.add("PartC1") class Product1(): """ It makes sense to use the Builder pattern only when your products are quite complex and require extensive configuration. Unlike in other creational patterns, different concrete builders can produce unrelated products. In other words, results of various builders may not always follow the same interface. """ def __init__(self) -> None: self.parts = [] def add(self, part: Any) -> None: self.parts.append(part) def list_parts(self) -> None: print(f"Product parts: {', '.join(self.parts)}", end="") class Director: """ The Director is only responsible for executing the building steps in a particular sequence. It is 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. """ def __init__(self) -> None: self._builder = None @property def builder(self) -> Builder: return self._builder @builder.setter def builder(self, builder: Builder) -> None: """ 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. """ self._builder = builder """ The Director can construct several product variations using the same building steps. """ def build_minimal_viable_product(self) -> None: self.builder.produce_part_a() def build_full_featured_product(self) -> None: self.builder.produce_part_a() self.builder.produce_part_b() self.builder.produce_part_c() if __name__ == "__main__": """ 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. """ director = Director() builder = ConcreteBuilder1() director.builder = builder print("Standard basic product: ") director.build_minimal_viable_product() builder.product.list_parts() print("\n") print("Standard full featured product: ") director.build_full_featured_product() builder.product.list_parts() print("\n") # Remember, the Builder pattern can be used without a Director class. print("Custom product: ") builder.produce_part_a() builder.produce_part_b() builder.product.list_parts() Standard basic product: Product parts: PartA1 Standard full featured product: Product parts: PartA1, PartB1, PartC1 Custom product: Product parts: PartA1, PartB1 ``` ### ruby ```ruby # The Builder interface specifies methods for creating the different parts of # the Product objects. class Builder # @abstract def produce_part_a raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'" end # @abstract def produce_part_b raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'" end # @abstract def produce_part_c raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'" end end # The Concrete Builder classes follow the Builder interface and provide specific # implementations of the building steps. Your program may have several # variations of Builders, implemented differently. class ConcreteBuilder1 < Builder # A fresh builder instance should contain a blank product object, which is # used in further assembly. def initialize reset end def reset @product = Product1.new end # 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 follow the same interface. Therefore, such # methods cannot be declared in the base Builder interface (at least 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 is not mandatory, and you can make your # builders wait for an explicit reset call from the client code before # disposing of the previous result. def product product = @product reset product end def produce_part_a @product.add('PartA1') end def produce_part_b @product.add('PartB1') end def produce_part_c @product.add('PartC1') end end # It makes sense to use the Builder pattern only when your products are quite # complex and require extensive configuration. # # Unlike in other creational patterns, different concrete builders can produce # unrelated products. In other words, results of various builders may not always # follow the same interface. class Product1 def initialize @parts = [] end # @param [String] part def add(part) @parts << part end def list_parts print "Product parts: #{@parts.join(', ')}" end end # The Director is only responsible for executing the building steps in a # particular sequence. It is 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 # @return [Builder] attr_accessor :builder def initialize @builder = nil end # 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. def builder=(builder) @builder = builder end # The Director can construct several product variations using the same # building steps. def build_minimal_viable_product @builder.produce_part_a end def build_full_featured_product @builder.produce_part_a @builder.produce_part_b @builder.produce_part_c end end # 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. director = Director.new builder = ConcreteBuilder1.new director.builder = builder puts 'Standard basic product: ' director.build_minimal_viable_product builder.product.list_parts puts "\n\n" puts 'Standard full featured product: ' director.build_full_featured_product builder.product.list_parts puts "\n\n" # Remember, the Builder pattern can be used without a Director class. puts 'Custom product: ' builder.produce_part_a builder.produce_part_b builder.product.list_parts Standard basic product: Product parts: PartA1 Standard full featured product: Product parts: PartA1, PartB1, PartC1 Custom product: Product parts: PartA1, PartB1 ``` ### rust ```rust let car = Car::default().places(5).gas(30) mod car; mod car_manual; use crate::components::{CarType, Engine, GpsNavigator, Transmission}; /// Builder defines how to assemble a car. pub trait Builder { type OutputType; fn set_car_type(&mut self, car_type: CarType); fn set_seats(&mut self, seats: u16); fn set_engine(&mut self, engine: Engine); fn set_transmission(&mut self, transmission: Transmission); fn set_gps_navigator(&mut self, gps_navigator: GpsNavigator); fn build(self) -> Self::OutputType; } pub use car::CarBuilder; pub use car_manual::CarManualBuilder; use crate::{ cars::Car, components::{CarType, Engine, GpsNavigator, Transmission}, }; use super::Builder; pub const DEFAULT_FUEL: f64 = 5f64; #[derive(Default)] pub struct CarBuilder { car_type: Option, engine: Option, gps_navigator: Option, seats: Option, transmission: Option, } impl Builder for CarBuilder { type OutputType = Car; fn set_car_type(&mut self, car_type: CarType) { self.car_type = Some(car_type); } fn set_engine(&mut self, engine: Engine) { self.engine = Some(engine); } fn set_gps_navigator(&mut self, gps_navigator: GpsNavigator) { self.gps_navigator = Some(gps_navigator); } fn set_seats(&mut self, seats: u16) { self.seats = Some(seats); } fn set_transmission(&mut self, transmission: Transmission) { self.transmission = Some(transmission); } fn build(self) -> Car { Car::new( self.car_type.expect("Please, set a car type"), self.seats.expect("Please, set a number of seats"), self.engine.expect("Please, set an engine configuration"), self.transmission.expect("Please, set up transmission"), self.gps_navigator, DEFAULT_FUEL, ) } } use crate::{ cars::Manual, components::{CarType, Engine, GpsNavigator, Transmission}, }; use super::Builder; #[derive(Default)] pub struct CarManualBuilder { car_type: Option, engine: Option, gps_navigator: Option, seats: Option, transmission: Option, } /// Builds a car manual instead of an actual car. impl Builder for CarManualBuilder { type OutputType = Manual; fn set_car_type(&mut self, car_type: CarType) { self.car_type = Some(car_type); } fn set_engine(&mut self, engine: Engine) { self.engine = Some(engine); } fn set_gps_navigator(&mut self, gps_navigator: GpsNavigator) { self.gps_navigator = Some(gps_navigator); } fn set_seats(&mut self, seats: u16) { self.seats = Some(seats); } fn set_transmission(&mut self, transmission: Transmission) { self.transmission = Some(transmission); } fn build(self) -> Manual { Manual::new( self.car_type.expect("Please, set a car type"), self.seats.expect("Please, set a number of seats"), self.engine.expect("Please, set an engine configuration"), self.transmission.expect("Please, set up transmission"), self.gps_navigator, ) } } mod car; mod manual; pub use car::Car; pub use manual::Manual; use crate::components::{CarType, Engine, GpsNavigator, Transmission}; pub struct Car { car_type: CarType, seats: u16, engine: Engine, transmission: Transmission, gps_navigator: Option, fuel: f64, } impl Car { pub fn new( car_type: CarType, seats: u16, engine: Engine, transmission: Transmission, gps_navigator: Option, fuel: f64, ) -> Self { Self { car_type, seats, engine, transmission, gps_navigator, fuel, } } pub fn car_type(&self) -> CarType { self.car_type } pub fn fuel(&self) -> f64 { self.fuel } pub fn set_fuel(&mut self, fuel: f64) { self.fuel = fuel; } pub fn seats(&self) -> u16 { self.seats } pub fn engine(&self) -> &Engine { &self.engine } pub fn transmission(&self) -> &Transmission { &self.transmission } pub fn gps_navigator(&self) -> &Option { &self.gps_navigator } } use crate::components::{CarType, Engine, GpsNavigator, Transmission}; pub struct Manual { car_type: CarType, seats: u16, engine: Engine, transmission: Transmission, gps_navigator: Option, } impl Manual { pub fn new( car_type: CarType, seats: u16, engine: Engine, transmission: Transmission, gps_navigator: Option, ) -> Self { Self { car_type, seats, engine, transmission, gps_navigator, } } } impl std::fmt::Display for Manual { fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result { writeln!(f, "Type of car: {:?}", self.car_type)?; writeln!(f, "Count of seats: {}", self.seats)?; writeln!( f, "Engine: volume - {}; mileage - {}", self.engine.volume(), self.engine.mileage() )?; writeln!(f, "Transmission: {:?}", self.transmission)?; match self.gps_navigator { Some(_) => writeln!(f, "GPS Navigator: Functional")?, None => writeln!(f, "GPS Navigator: N/A")?, }; Ok(()) } } #[derive(Copy, Clone, Debug)] pub enum CarType { CityCar, SportsCar, Suv, } #[derive(Debug)] pub enum Transmission { SingleSpeed, Manual, Automatic, SemiAutomatic, } pub struct Engine { volume: f64, mileage: f64, started: bool, } impl Engine { pub fn new(volume: f64, mileage: f64) -> Self { Self { volume, mileage, started: false, } } pub fn on(&mut self) { self.started = true; } pub fn off(&mut self) { self.started = false; } pub fn started(&self) -> bool { self.started } pub fn volume(&self) -> f64 { self.volume } pub fn mileage(&self) -> f64 { self.mileage } pub fn go(&mut self, mileage: f64) { if self.started() { self.mileage += mileage; } else { println!("Cannot go(), you must start engine first!"); } } } pub struct GpsNavigator { route: String, } impl GpsNavigator { pub fn new() -> Self { Self::from_route( "221b, Baker Street, London to Scotland Yard, 8-10 Broadway, London".into(), ) } pub fn from_route(route: String) -> Self { Self { route } } pub fn route(&self) -> &String { &self.route } } use crate::{ builders::Builder, components::{CarType, Engine, GpsNavigator, Transmission}, }; /// Director knows how to build a car. /// /// However, a builder can build a car manual instead of an actual car, /// everything depends on the concrete builder. pub struct Director; impl Director { pub fn construct_sports_car(builder: &mut impl Builder) { builder.set_car_type(CarType::SportsCar); builder.set_seats(2); builder.set_engine(Engine::new(3.0, 0.0)); builder.set_transmission(Transmission::SemiAutomatic); builder.set_gps_navigator(GpsNavigator::new()); } pub fn construct_city_car(builder: &mut impl Builder) { builder.set_car_type(CarType::CityCar); builder.set_seats(2); builder.set_engine(Engine::new(1.2, 0.0)); builder.set_transmission(Transmission::Automatic); builder.set_gps_navigator(GpsNavigator::new()); } pub fn construct_suv(builder: &mut impl Builder) { builder.set_car_type(CarType::Suv); builder.set_seats(4); builder.set_engine(Engine::new(2.5, 0.0)); builder.set_transmission(Transmission::Manual); builder.set_gps_navigator(GpsNavigator::new()); } } #![allow(unused)] mod builders; mod cars; mod components; mod director; use builders::{Builder, CarBuilder, CarManualBuilder}; use cars::{Car, Manual}; use director::Director; fn main() { let mut car_builder = CarBuilder::default(); // Director gets the concrete builder object from the client // (application code). That's because application knows better which // builder to use to get a specific product. Director::construct_sports_car(&mut car_builder); // The final product is often retrieved from a builder object, since // Director is not aware and not dependent on concrete builders and // products. let car: Car = car_builder.build(); println!("Car built: {:?}\n", car.car_type()); let mut manual_builder = CarManualBuilder::default(); // Director may know several building recipes. Director::construct_city_car(&mut manual_builder); // The final car manual. let manual: Manual = manual_builder.build(); println!("Car manual built:\n{}", manual); } Car built: SportsCar Car manual built: Type of car: CityCar Count of seats: 2 Engine: volume - 1.2; mileage - 0 Transmission: Automatic GPS Navigator: Functional ``` ### swift ```swift import XCTest /// The Builder interface specifies methods for creating the different parts of /// the Product objects. protocol Builder { func producePartA() func producePartB() func producePartC() } /// The Concrete Builder classes follow the Builder interface and provide /// specific implementations of the building steps. Your program may have /// several variations of Builders, implemented differently. class ConcreteBuilder1: Builder { /// A fresh builder instance should contain a blank product object, which is /// used in further assembly. private var product = Product1() func reset() { product = Product1() } /// All production steps work with the same product instance. func producePartA() { product.add(part: "PartA1") } func producePartB() { product.add(part: "PartB1") } func producePartC() { product.add(part: "PartC1") } /// 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 follow the same interface. /// Therefore, such methods cannot be declared in the base Builder interface /// (at least 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 is not mandatory, /// and you can make your builders wait for an explicit reset call from the /// client code before disposing of the previous result. func retrieveProduct() -> Product1 { let result = self.product reset() return result } } /// The Director is only responsible for executing the building steps in a /// particular sequence. It is 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 { private var 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. func update(builder: Builder) { self.builder = builder } /// The Director can construct several product variations using the same /// building steps. func buildMinimalViableProduct() { builder?.producePartA() } func buildFullFeaturedProduct() { builder?.producePartA() builder?.producePartB() builder?.producePartC() } } /// It makes sense to use the Builder pattern only when your products are quite /// complex and require extensive configuration. /// /// Unlike in other creational patterns, different concrete builders can produce /// unrelated products. In other words, results of various builders may not /// always follow the same interface. class Product1 { private var parts = [String]() func add(part: String) { self.parts.append(part) } func listParts() -> String { return "Product parts: " + parts.joined(separator: ", ") + "\n" } } /// 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 Client { // ... static func someClientCode(director: Director) { let builder = ConcreteBuilder1() director.update(builder: builder) print("Standard basic product:") director.buildMinimalViableProduct() print(builder.retrieveProduct().listParts()) print("Standard full featured product:") director.buildFullFeaturedProduct() print(builder.retrieveProduct().listParts()) // Remember, the Builder pattern can be used without a Director class. print("Custom product:") builder.producePartA() builder.producePartC() print(builder.retrieveProduct().listParts()) } // ... } /// Let's see how it all comes together. class BuilderConceptual: XCTestCase { func testBuilderConceptual() { let director = Director() Client.someClientCode(director: director) } } Standard basic product: Product parts: PartA1 Standard full featured product: Product parts: PartA1, PartB1, PartC1 Custom product: Product parts: PartA1, PartC1 import Foundation import XCTest class BaseQueryBuilder { typealias Predicate = (Model) -> (Bool) func limit(_ limit: Int) -> BaseQueryBuilder { return self } func filter(_ predicate: @escaping Predicate) -> BaseQueryBuilder { return self } func fetch() -> [Model] { preconditionFailure("Should be overridden in subclasses.") } } class RealmQueryBuilder: BaseQueryBuilder { enum Query { case filter(Predicate) case limit(Int) /// ... } fileprivate var operations = [Query]() @discardableResult override func limit(_ limit: Int) -> RealmQueryBuilder { operations.append(Query.limit(limit)) return self } @discardableResult override func filter(_ predicate: @escaping Predicate) -> RealmQueryBuilder { operations.append(Query.filter(predicate)) return self } override func fetch() -> [Model] { print("RealmQueryBuilder: Initializing RealmDataProvider with \(operations.count) operations:") return RealmProvider().fetch(operations) } } class CoreDataQueryBuilder: BaseQueryBuilder { enum Query { case filter(Predicate) case limit(Int) case includesPropertyValues(Bool) /// ... } fileprivate var operations = [Query]() override func limit(_ limit: Int) -> CoreDataQueryBuilder { operations.append(Query.limit(limit)) return self } override func filter(_ predicate: @escaping Predicate) -> CoreDataQueryBuilder { operations.append(Query.filter(predicate)) return self } func includesPropertyValues(_ toggle: Bool) -> CoreDataQueryBuilder { operations.append(Query.includesPropertyValues(toggle)) return self } override func fetch() -> [Model] { print("CoreDataQueryBuilder: Initializing CoreDataProvider with \(operations.count) operations.") return CoreDataProvider().fetch(operations) } } /// Data Providers contain a logic how to fetch models. Builders accumulate /// operations and then update providers to fetch the data. class RealmProvider { func fetch(_ operations: [RealmQueryBuilder.Query]) -> [Model] { print("RealmProvider: Retrieving data from Realm...") for item in operations { switch item { case .filter(_): print("RealmProvider: executing the 'filter' operation.") /// Use Realm instance to filter results. break case .limit(_): print("RealmProvider: executing the 'limit' operation.") /// Use Realm instance to limit results. break } } /// Return results from Realm return [] } } class CoreDataProvider { func fetch(_ operations: [CoreDataQueryBuilder.Query]) -> [Model] { /// Create a NSFetchRequest print("CoreDataProvider: Retrieving data from CoreData...") for item in operations { switch item { case .filter(_): print("CoreDataProvider: executing the 'filter' operation.") /// Set a 'predicate' for a NSFetchRequest. break case .limit(_): print("CoreDataProvider: executing the 'limit' operation.") /// Set a 'fetchLimit' for a NSFetchRequest. break case .includesPropertyValues(_): print("CoreDataProvider: executing the 'includesPropertyValues' operation.") /// Set an 'includesPropertyValues' for a NSFetchRequest. break } } /// Execute a NSFetchRequest and return results. return [] } } protocol DomainModel { /// The protocol groups domain models to the common interface } private struct User: DomainModel { let id: Int let age: Int let email: String } class BuilderRealWorld: XCTestCase { func testBuilderRealWorld() { print("Client: Start fetching data from Realm") clientCode(builder: RealmQueryBuilder()) print() print("Client: Start fetching data from CoreData") clientCode(builder: CoreDataQueryBuilder()) } fileprivate func clientCode(builder: BaseQueryBuilder) { let results = builder.filter({ $0.age < 20 }) .limit(1) .fetch() print("Client: I have fetched: " + String(results.count) + " records.") } } Client: Start fetching data from Realm RealmQueryBuilder: Initializing RealmDataProvider with 2 operations: RealmProvider: Retrieving data from Realm... RealmProvider: executing the 'filter' operation. RealmProvider: executing the 'limit' operation. Client: I have fetched: 0 records. Client: Start fetching data from CoreData CoreDataQueryBuilder: Initializing CoreDataProvider with 2 operations. CoreDataProvider: Retrieving data from CoreData... CoreDataProvider: executing the 'filter' operation. CoreDataProvider: executing the 'limit' operation. Client: I have fetched: 0 records. ``` ### typescript ```typescript /** * The Builder interface specifies methods for creating the different parts of * the Product objects. */ interface Builder { producePartA(): void; producePartB(): void; producePartC(): void; } /** * The Concrete Builder classes follow the Builder interface and provide * specific implementations of the building steps. Your program may have several * variations of Builders, implemented differently. */ class ConcreteBuilder1 implements Builder { private product: Product1; /** * A fresh builder instance should contain a blank product object, which is * used in further assembly. */ constructor() { this.reset(); } public reset(): void { this.product = new Product1(); } /** * All production steps work with the same product instance. */ public producePartA(): void { this.product.parts.push('PartA1'); } public producePartB(): void { this.product.parts.push('PartB1'); } public producePartC(): void { this.product.parts.push('PartC1'); } /** * 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 follow the same interface. * Therefore, such methods cannot be declared in the base Builder interface * (at least 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 is not mandatory, and * you can make your builders wait for an explicit reset call from the * client code before disposing of the previous result. */ public getProduct(): Product1 { const result = this.product; this.reset(); return result; } } /** * It makes sense to use the Builder pattern only when your products are quite * complex and require extensive configuration. * * Unlike in other creational patterns, different concrete builders can produce * unrelated products. In other words, results of various builders may not * always follow the same interface. */ class Product1 { public parts: string[] = []; public listParts(): void { console.log(`Product parts: ${this.parts.join(', ')}\n`); } } /** * The Director is only responsible for executing the building steps in a * particular sequence. It is 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 { private 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. */ public setBuilder(builder: Builder): void { this.builder = builder; } /** * The Director can construct several product variations using the same * building steps. */ public buildMinimalViableProduct(): void { this.builder.producePartA(); } public buildFullFeaturedProduct(): void { this.builder.producePartA(); this.builder.producePartB(); this.builder.producePartC(); } } /** * 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. */ function clientCode(director: Director) { const builder = new ConcreteBuilder1(); director.setBuilder(builder); console.log('Standard basic product:'); director.buildMinimalViableProduct(); builder.getProduct().listParts(); console.log('Standard full featured product:'); director.buildFullFeaturedProduct(); builder.getProduct().listParts(); // Remember, the Builder pattern can be used without a Director class. console.log('Custom product:'); builder.producePartA(); builder.producePartC(); builder.getProduct().listParts(); } const director = new Director(); clientCode(director); Standard basic product: Product parts: PartA1 Standard full featured product: Product parts: PartA1, PartB1, PartC1 Custom product: Product parts: PartA1, PartC1 ```