The builder pattern stands out as a design pattern that is a particularly useful solution to object creation problems in object-oriented programming. It is particularly suited to dynamically creating objects in a step-by-step process.

Typically, this pattern begins with either a default or a required state, then offers a series of options through setter methods to update the default. These setter methods uniquely return the in-progress instance of the builder, rather than the final target object being built. Then, only at the end is there a Build() method used for materializing the target object.

Let’s consider the following simple example to get a better understanding:

public class Car
{
    public string Make { get; set; }
    public string Model { get; set; }
    public int Year { get; set; }
}

public class CarBuilder
{
    private Car car = new Car();

    public CarBuilder WithMake(string make)
    {
        car.Make = make;
        return this;
    }

    public CarBuilder WithModel(string model)
    {
        car.Model = model;
        return this;
    }

    public CarBuilder WithYear(int year)
    {
        car.Year = year;
        return this;
    }

    public Car Build()
    {
        return car;
    }
}

Then we can create an instance of Car through a series of consecutive (or fluent) method calls, like:

var myCar = new CarBuilder()
    .WithMake("Toyota")
    .WithModel("Corolla")
    .WithYear(2021)
    .Build();

Of course, on the web, you can find a lot of variations on this pattern, maybe following different naming conventions, but maintaining common features like that fluent style.

A Generic Approach

To avoid implementing one builder class per target class, let’s look at how we can leverage generics in C# to solve this problem. My generics example is also very simplistic as it’s just for demo purposes. In the real world, you can find much longer implementations or a set of multiple collaborating builders working together.

This approach could be used for virtually any object type as long as it exposes some property setters, which you typically find in POCOs (Plain-Old CLR Objects), maybe working as DTOs (Data Transfer Objects) or models being mapped between the different layers in an application.

Let’s dive into a simplified solution that embodies these principles. Check out the function below:

public static T Create<T>(Action<T>? perform = null) where T : new()
{
    var newObject = new T();
    perform?.Invoke(newObject);

    return newObject;
}

It’s just a function, but you get every essential purpose for it and this corresponding calling code:

var myCar = Create<Car>(with =>
    {
        with.Make = "Toyota";
        with.Model = "Corolla";
        with.Year = 2021;
    });

This is a very flexible solution. For example, notice this simple variation for supporting different potential use cases:

// Just leave the default values for all properties
var myDefaultCar = Create<Car>();

// Set partial state
var myPartialCar = Create<Car>(with =>
    {
        with.Make = "Toyota";
        with.Year = 2021;
    });

This generic approach excels in testing scenarios, where the pattern is better known more specifically as the Test Data Builder pattern. Creating diverse test cases is crucial to confirm that a particular functionality behaves as expected under various scenarios. In this context, stub objects, typically derived from input model objects, are employed. Therefore, it is essential to have a rapid and efficient method for constructing these variations, as facilitated by the generic builder implementation.

By now, you should have a good grasp of the concept, so it’s your turn to extend or adapt these insights to fit your needs.

For instance, suppose that now our target class (Car) has a constructor requiring a parameter value intended for a property (e.g. ‘Make’), also removing the public accessor for its setter. This would make our function ‘Create<T>’ unuseful for this specific case. However, again, this is not about suggesting a specific implementation but a guideline instead. In this case, you could create an extension method like this:

public static T With<T>(this T target, Action<T> with)
{
    with(target);

    return target;
}

For being used as:

var myCar = new Car("Toyota").With(x =>
    {
        x.Model = "Corolla";
        x.Year = 2021;
    });

Though this is a different implementation, it accomplished the same thing. That is a very pluggable solution that can be ported to the implementation of other patterns and approaches. It requires minimal code as is very reusable code, allowing you to be focused on the real thing you’re developing like business logic or testing logic.

Now that you’ve seen it, how would you use this pattern?