What is the Builder design pattern?

The Builder design pattern is a creational pattern that allows for step-by-step construction of complex objects. It separates the construction process from the object's representation, enabling the same construction process to create different representations of the object.

Key features:

• Separation of construction and representation: The algorithm for creating the object is independent of the specific details of the object being created.
• Step-by-step creation: The object is created by calling a sequence of builder methods.
• Different object variations: The same builder can be used to create objects with different compositions or configurations.
• Use of Director (Optional): A Director object can manage the construction process, defining the sequence of builder method calls.

Pattern structure:

• Builder: An interface or abstract class defining methods for constructing different parts of the object.
• ConcreteBuilder: Implements the Builder interface and provides specific implementations for constructing a particular type of object. It contains methods for creating parts of the object and a method to retrieve the constructed object.
• Product: The complex object that is being built.
• Director (Optional): A class that uses a Builder object to create a Product. It defines the order of calling Builder methods.

Advantages:

• Allows creating objects with many optional parameters, avoiding "telescopic constructors" (multiple constructors with different parameter sets).
• Enables internal representation changes of the object without modifying the client using the Builder.
• Facilitates adding new types of construction.
• Improves code readability and maintainability when creating complex objects.

Disadvantages:

• Increases the number of classes in the project.
• May be excessive for simple objects.

Usage example:

Imagine creating a "Car" object with various options (engine, color, transmission, etc.). Instead of multiple constructors, you can use a Builder for step-by-step configuration of the car.

// Product
class Car {
    private String engine;
    private String color;
    private String transmission;

    public void setEngine(String engine) {
        this.engine = engine;
    }

    public void setColor(String color) {
        this.color = color;
    }

    public void setTransmission(String transmission) {
        this.transmission = transmission;
    }

    @Override
    public String toString() {
        return "Car{" +
               "engine='" + engine + '\'' +
               ", color='" + color + '\'' +
               ", transmission='" + transmission + '\'' +
               '}';
    }
}

// Builder
interface CarBuilder {
    void buildEngine(String engine);
    void buildColor(String color);
    void buildTransmission(String transmission);
    Car getResult();
}

// ConcreteBuilder
class SportCarBuilder implements CarBuilder {
    private Car car = new Car();

    @Override
    public void buildEngine(String engine) {
        car.setEngine(engine);
    }

    @Override
    public void buildColor(String color) {
        car.setColor(color);
    }

    @Override
    public void buildTransmission(String transmission) {
        car.setTransmission(transmission);
    }

    @Override
    public Car getResult() {
        return car;
    }
}

// Client (or Director)
class CarManufacturing {
    public Car constructSportCar(CarBuilder builder) {
        builder.buildEngine("V8");
        builder.buildColor("Red");
        builder.buildTransmission("Automatic");
        return builder.getResult();
    }
}

In this example, Car is the Product, CarBuilder is the Builder, SportCarBuilder is the ConcreteBuilder, and CarManufacturing can act as the Director.