The Builder Pattern in C#: How To Leverage Extension Methods Creatively

Design patterns play a pivotal role in software engineering by helping shape efficient and maintainable code. Specifically, within the realm of C#, these patterns provide developers with blueprints to tackle common problems. One such pattern, the builder pattern, stands out for its ability to streamline the creation of complex objects. In this article, we’ll delve into the intricacies of the builder pattern in C# and explore how it can be supercharged using extension methods.


What’s In This Article: The Builder Pattern In C#

Remember to follow on these other platforms:


Understanding the Builder Pattern in C#

The builder pattern is a design pattern that addresses the challenge of constructing complex objects. In the realm of C#, a language that emphasizes object-oriented programming, understanding and implementing the builder pattern in C# can be a game-changer.

So, what’s the essence of the builder pattern? It’s all about decoupling the process of constructing a complex object from its actual representation. This decoupling allows for the creation of different representations using the same construction process. Imagine you’re building a house. The process involves laying a foundation, erecting walls, and placing a roof. This process remains consistent, but the materials and designs can vary, leading to different house representations.

The builder pattern in C# becomes particularly valuable because C# applications often involve creating intricate objects with numerous optional components or configurations. Manually handling these configurations can lead to bloated constructors and hard-to-maintain code. Enter the builder pattern: it streamlines this process, ensuring that object creation is both flexible and organized. By leveraging the builder pattern in C#, developers can construct objects step-by-step, ensuring each component is added in a controlled and modular manner. Layer in a nice fluent API and you have a beautiful thing!


Extension Methods in C#: A Primer

C# is a language rich in features, and one of its standout capabilities is the use of extension methods. But what exactly are they? Extension methods empower developers to augment existing types with new methods, all without modifying the original type or creating a new derived type.

At first glance, this might seem like magic. How can you add functionality to a class without altering its source code? The secret lies in C#’s ability to define static methods within static classes that operate as if they were instance methods of the type they extend. This means you can introduce new behaviors to existing classes seamlessly.

For instance, let’s say you have a string and you want a method that checks if it’s a palindrome. Instead of creating a new derived string class with this method, you can simply create an extension method for the existing string type.

The synergy between the builder pattern and extension methods in C# is evident. While the builder pattern focuses on modular and step-by-step object construction, extension methods offer a way to enhance and expand the capabilities of the builder without altering its core. This combination allows for a more flexible and extensible approach to object creation in C#.


Implementing the Builder Pattern Using Extension Methods

Setting the Foundation:

  • Director Class: This class will orchestrate the construction process. It will have a method that accepts a builder and uses it to produce a product.
  • Builder Interface: This interface will define the necessary steps to construct a product.
  • Product Class: Represents the complex object that we aim to construct.

The Builder Pattern in C# Using Extension Methods

When we incorporate extension methods in C#, we can actually change up some of the core pieces of the builder pattern. This works extremely well in situations where the object that we are building has a collection of objects that can be instantiated or configured differently. In fact, if you’ve been creating ASP.NET Core applications, you’ve probably seen this! Here’s an example from this article that partially demonstrates this:

var host = builder.Build();
host.Services.UseAutofacContainer(containerBuilder.Build());

While not exactly the builder pattern, this extension method used in this setting lends itself well to explaining the benefits. Non-owners of the class (i.e. third-party code) can “extend” the class by offering extensions, and the context here is configuring application services before we run the application. While we’re not “building” the app, it’s in a similar framing.

Let’s take a look at the following builder design pattern code that leverages extension methods. We’ll be building a service manager that manages services. Third-party developers are able to create their own services and we’ll look at how to extend the builder:

public interface IServiceManager
{
    IReadOnlyList<IService> Services { get; }

    Task StopServicesAsync(CancellationToken cancellationToken);

    Task StartServicesAsync(CancellationToken cancellationToken);
}

public sealed class ServiceManager : IServiceManager
{
    private readonly IReadOnlyList<IService> _services;

    public ServiceManager(IReadOnlyList<IService> services)
    {
        _services = services;
    }

    public IReadOnlyList<IService> Services 
        => _services;

    public Task StartServicesAsync(
        CancellationToken cancellationToken)
    {
        // assume there's some code here to start services
        return Task.CompletedTask;
    }

    public Task StopServicesAsync(
        CancellationToken cancellationToken)
    {
        // assume there's some code here to stop services
        return Task.CompletedTask;
    }
}

public sealed class ServiceManagerBuilder
{
    private readonly List<IService> _services;

    public ServiceManagerBuilder()
    {
        _services = new List<IService>();
    }

    public ServiceManagerBuilder(
        IEnumerable<IService> services)
        : this()
    {
        _services.AddRange(services);
    }

    public IReadOnlyList<IService> Services =>
        _services;

    public IServiceManager Build()
    {
        // make a copy of the collection to prevent
        // the collection from being modified after
        // the service manager is built
        var copy = _services.ToArray();
        var serviceManager = new ServiceManager(copy);
        return serviceManager;
    }
}

The code above provides a basic builder for adding services. There’s nothing really creative here compared to the basics for the builder pattern, but let’s see how we can change that up.

Third-Party Extension Methods For The Builder Pattern in C#

Let’s turn up the interesting dial on the previous example! We had a simple builder that could be used to add simple implementations of a service. But perhaps third parties have their own services they want configured to get added into the service manager.

Let’s use an example where a notification system defined by a third-party wants to offer first-party-like syntax for building a service manager with the notification system:

public static class ServiceManagerBuilderNotificationExtensions
{
    public static ServiceManagerBuilder WithNotificationService(
        this ServiceManagerBuilder builder,
        string notificationApiKey,
        string notificationApiSecret,
        int interval)
    {
        List<IService> services = builder.Services.ToList();

        // or maybe we need to call a factory or have more complex setup...
        // this will get masked behind the extension method API
        var notificationService = new NotificationService(
            notificationApiKey,
            notificationApiSecret,
            interval);
        services.Add(notificationService);

        var newBuilder = new ServiceManagerBuilder(
            services);
        return newBuilder;
    }
}

Some things to mention:

  • We can hide complex setups for objects behind the extension methods and provide a nice API for creating them. They’ll get added to the builder and we can continue on!
  • We can build a really nice fluent-style API! This makes the builder pattern read in a very friendly way.
  • I use the word “With” here in the method name because I am actually returning a NEW builder, not modifying the original. Otherwise, I might have just used the word “Add”. You should go with a naming scheme that makes sense for you!

What does that last point mean? Consider code like this:

IServiceManager serviceManager = new ServiceManagerBuilder()
    .AddNotificationService("abc", "123", 456)
    .AddSomeOtherService("Nick is cool")
    .AddBlogService("https://www.devleader.ca")
    .Build();

While I’ve added some imaginary methods there, look how nice that fluid extension method syntax makes the builder design pattern for us!


Concrete Builder in C#

In C#, a concrete builder is part of the Builder design pattern, which is used to construct a complex object step by step. As we’ve seen, the Builder pattern separates the construction of a complex object from its representation. This allows the same construction process to create different representations. When we refer to concrete builders, these are simply just the actual implementation of the builder class.

The Role of Concrete Builders

The following points elaborate further on what concrete builders are with respect to the Builder pattern:

  • Implementation of Builder Interface: A Concrete Builder implements the operations defined in the Builder interface for creating parts of a product.
  • Construction Details: It provides the specific details for building a part of the complex object. Different concrete builders can implement the same steps differently.
  • Storing the Constructed Product: It often maintains the product it builds; the product is retrieved by the client code, typically through a GetResult or similar method.

Example C# Code for a Concrete Builder

Here’s a simplified example of a concrete builder in a C# context:

public interface IHouseBuilder
{
    void BuildWalls();
    void BuildDoors();
    House GetHouse();
}

public class ConcreteHouseBuilder : IHouseBuilder
{
    private House _house = new House();

    public void BuildWalls()
    {
        _house.AddPart("Concrete Walls");
    }

    public void BuildDoors()
    {
        _house.AddPart("Wooden Door");
    }

    public House GetHouse()
    {
        return _house;
    }
}

public class House
{
    private List<string> _parts = new List<string>();

    public void AddPart(string part)
    {
        _parts.Add(part);
    }

    public string Describe()
    {
        return "House with: " + string.Join(", ", _parts);
    }
}

In this example, ConcreteHouseBuilder is a concrete builder that implements the IHouseBuilder interface. It provides specific implementations for BuildWalls and BuildDoors, and maintains the House object it is building. The client code would use the ConcreteHouseBuilder to construct a House object in a step-by-step manner, and then retrieve the final product using the GetHouse method.

Using concrete builders, the complex construction logic is encapsulated, leading to cleaner and more maintainable code. The client code can then focus on the required sequence of building steps, rather than the specifics of each step.


Comparing the Builder Pattern in C# to Other Design Patterns

In the realm of C# development, design patterns serve as tried-and-true solutions to recurring challenges. Each pattern has its strengths, tailored to address specific design problems:

  1. Builder Pattern: This pattern shines when there’s a need to construct a complex object, especially when the construction process involves multiple steps or configurations. For example, when creating a Document object that can have various formats, headers, footers, and body content, the builder pattern allows for a step-by-step construction, ensuring clarity and flexibility.
  2. Singleton Pattern: The singleton pattern is all about ensuring that a class has only one instance and provides a global point of access to that instance. This is particularly useful when you want to control access to shared resources, such as configuration settings or a shared cache.
  3. Factory Pattern: If your application requires the creation of objects where the exact type isn’t known until runtime, the factory pattern comes into play. It provides an interface for creating instances of a class, with its subclasses deciding which class to instantiate. For instance, a DatabaseFactory might produce different database connection objects based on the connection string provided.
  4. Strategy Pattern: Suppose you have multiple algorithms or strategies for a specific task and want to switch between them dynamically. In that case, the strategy pattern is a solid choice. For example, a SortingStrategy class could allow for different sorting algorithms to be plugged in and used interchangeably.

When choosing a design pattern, it’s crucial to analyze the specific problem you’re trying to solve. If your primary concern is building a complex object in a controlled, step-by-step manner, the builder pattern in C# is ideal. However, if you’re more focused on resource access control or dynamic object creation, patterns like singleton and factory might be more fitting.


Best Practices and Tips for C# Developers

The builder pattern, while a powerful tool in the software developer’s arsenal, requires careful implementation to truly shine, especially in a language as versatile as C#. Here are some best practices and tips tailored for C# developers:

  1. Clear Interfaces: Always ensure that the builder interface is clear and intuitive. This not only makes the code more readable but also ensures that other developers can easily understand and use the builder you’ve designed.
  2. Modular Construction Steps: One of the main advantages of the builder pattern is its ability to break down the construction of a complex object into smaller, more manageable steps. Ensure that each step in the builder is modular and focused on a single aspect of the object being built.
  3. Leverage Extension Methods: C# offers the powerful feature of extension methods, allowing developers to add new methods to existing types without altering them. This can be particularly useful with the builder pattern, enabling you to extend and customize builders without modifying the original code. For instance, if a third-party library provides a builder, but it lacks some features you need, extension methods can come to the rescue.
  4. Avoid Overcomplication: While the builder pattern is meant to handle complexity, it’s essential not to introduce unnecessary complexity. If an object is simple and doesn’t require multiple configurations, a builder might be overkill.
  5. Beware of Pitfalls with Extension Methods: While extension methods are powerful, they can sometimes lead to confusion, especially if multiple libraries extend the same type in conflicting ways. Always ensure that your extension methods are clearly named and documented to avoid potential clashes.

The Builder Pattern in C# Wrapped Up

The builder pattern stands out amongst the design patterns for object creation and configuration, especially in the rich landscape of C# development. Its ability to simplify complex construction processes, combined with the extensibility offered by C# extension methods, makes it a must-know design pattern for any serious C# developer.

As with all design patterns, the key is understanding when and how to use it. The builder pattern isn’t a one-size-fits-all solution, but in the right scenarios, it can drastically improve code readability, maintainability, and flexibility.

For budding C# developers and seasoned professionals alike, diving deep into the builder pattern and experimenting with its implementation, especially with the added twist of extension methods, can lead to cleaner, more modular code. So, take the leap, start building, and see where the builder pattern can take your C# projects!


Frequently Asked Questions – The Builder Pattern in C#

What is the difference between the builder pattern and the singleton pattern?

The builder pattern shines when there’s a need to construct a complex object, especially when the construction process involves multiple steps or configurations. The singleton pattern is all about ensuring that a class has only one instance and provides a global point of access to that instance. This is particularly useful when you want to control access to shared resources, such as configuration settings or a shared cache.

What is the difference between the builder pattern and the factory pattern?

The builder pattern shines when there’s a need to construct a complex object, especially when the construction process involves multiple steps or configurations. However, if your application requires the creation of objects where the exact type isn’t known until runtime, the factory pattern comes into play. It provides an interface for creating instances of a class, with its subclasses deciding which class to instantiate. For instance, a DatabaseFactory might produce different database connection objects based on the connection string provided.

What is the difference between the builder pattern and the strategy pattern?

The builder pattern shines when there’s a need to construct a complex object, especially when the construction process involves multiple steps or configurations. However, suppose you have multiple algorithms or strategies for a specific task and want to switch between them dynamically. In that case, the strategy pattern is a solid choice. For example, a SortingStrategy class could allow for different sorting algorithms to be plugged in and used interchangeably.

What are concrete builders with respect to the builder pattern?

A concrete builder is part of the Builder design pattern. It’s the implementation which is used to construct a complex object step by step.

author avatar
Nick Cosentino Principal Software Engineering Manager
Principal Software Engineering Manager at Microsoft. Views are my own.

Leave a Reply