When building software systems, developers often face situations where objects become complex and contain many optional properties. Creating such objects using traditional constructors quickly becomes difficult to manage.
The Builder Design Pattern solves this problem by allowing objects to be constructed step-by-step, separating the construction logic from the object representation.
The Builder pattern is part of the Creational Design Patterns, which focus on how objects are created.
Definition of Builder Pattern
The Builder Pattern is defined as:
A creational design pattern that separates the construction of a complex object from its representation, allowing the same construction process to create different representations.
In simple words:
- It builds objects step by step
- It avoids complex constructors
- It makes object creation readable and flexible
The Core Problem Builder Solves
To understand Builder deeply, we must first understand the problem it solves.
Imagine we have a class representing a User.
public class User
{
public string Name;
public string Email;
public string Phone;
public string Address;
public int Age;
}Now suppose we create a constructor.
public User(string name, string email, string phone, string address, int age)
{
Name = name;
Email = email;
Phone = phone;
Address = address;
Age = age;
}Usage:
var user = new User("Avinash", "avinash@gmail.com", "999999", "Ahmedabad", 30);Problems with This Approach:
Hard to read
new User("A", "B", "C", "D", 30)You cannot immediately tell which value represents what.
Parameter Order Problem
If parameters are swapped accidentally:
new User("Avinash", "999999", "avinash@gmail.com", "Ahmedabad", 30);Now Email and Phone are incorrect, but the compiler may not detect it.
Too Many Optional Fields
What if Address is optional?
You still must pass it.
Constructor Explosion (Telescoping Constructors)
You might create many constructors:
User(name)
User(name, email)
User(name, email, phone)
User(name, email, phone, address)What is telescoping constructor problem?
In object-oriented programming, constructors are used to initialize object properties during creation. But when a class has many fields—say, 10 or more—using overloaded constructors to handle different combinations of parameters leads to a telescoping constructor problem.
Why telescoping constructor is a problem?
- You end up writing multiple constructors with increasing parameters.
- It becomes hard to read, maintain, and extend.
- The order of parameters can be confusing and error-prone.
Builder Pattern Solution
Instead of constructing the object in one big constructor, we build it step-by-step.
Example:
var user = new UserBuilder()
.SetName("Avinash")
.SetEmail("avinash@gmail.com")
.SetAge(30)
.Build();Now the code is:
- readable
- flexible
- maintainable
Structure of Builder Pattern
Builder Pattern usually consists of four components.
- Product – This is the complex object being built. It usually doesn’t have a simple constructor because it has many parts or configuration options.
- Builder – This defines the “blueprint” for construction. It lists all the possible steps (methods) required to create the product, but it doesn’t implement them.
- Concrete Builder – This is the worker that actually does the heavy lifting. It implements the Builder interface, maintains the state of the construction, and provides a method to fetch the final Product.
- Director (Optional) – This is the “manager.” Instead of the client calling every build step manually, the Director knows the specific sequence required to build a particular flavor of the product (e.g., a “Luxury Car” vs. a “Manual Car”).
Let’s understand this with a code –
Let’s take the class User as a Product –
Product
public class User
{
public string Name;
public string Email;
public string Phone;
public string Address;
public int Age;
}This will be the final product being build.
Now we need Builder
Builder
public interface IUserBuilder
{
void SetName(string name);
void SetEmail(string email);
void SetPhone(string phone);
void SetAddress(string address);
void SetAge(int Age);
User Build();
}Now this interface will act as a contract that will tell the concrete builder what to build.
Now let’s implement it in a concrete builder
Concrete Builder
public class UserBuilder : IUserBuilder
{
private User _user = new User();
public void SetName(string name)
{
_user.Name = name;
}
public void SetEmail(string email)
{
_user.Email = email;
}
public void SetPhone(string phone)
{
_user.Phone = phone;
}
public void SetAddress(string address)
{
_user.Address = address;
}
public void SetAge(int Age)
{
_user.Age = Age;
}
public User Build()
{
return _user;
}
}You can see now the concrete builder will have the methods to assign values to the contents inside User and has a build method to return what user it has built.
Let’s Use it in real world
UserBuilder userBuilder = new UserBuilder();
userBuilder.SetName("Avinash");
userBuilder.SetEmail("ajoshi0100@abc.com");
userBuilder.SetPhone("12345666");
userBuilder.SetAddress("123 lorem ipsum");
userBuilder.SetAge(30);
User user = userBuilder.Build();See no big hustle to build the constructor, this is readable and clean.
Imagine a real application where different types of users exist.
Example:
- Admin User
- Customer User
- Guest User
- Premium User
Each type may require different configuration.
Instead of repeating this logic everywhere, we introduce a Director.
Director
Director is a class that controls how the object should be built.
It decides:
- Which steps to call
- In what order
- With what values
So the Director manages the building process.
public class UserDirector
{
public User BuildAdminUser(IUserBuilder builder)
{
builder.SetName("Admin");
builder.SetEmail("admin@company.com");
builder.SetPhone("1111111111");
builder.SetAddress("Head Office");
builder.SetAge(35);
return builder.Build();
}
public User BuildCustomerUser(IUserBuilder builder)
{
builder.SetName("Customer");
builder.SetEmail("customer@gmail.com");
builder.SetPhone("9999999999");
builder.SetAddress("Customer Address");
builder.SetAge(25);
return builder.Build();
}
}This class standardizes the building process.
IUserBuilder builder = new UserBuilder();
UserDirector director = new UserDirector();
User admin = director.BuildAdminUser(builder);The builder is first created and then director uses that builder to define how and what the builder with do with the builder. This is called direction.
Executes in this way:
- Client creates the builder.
- Client creates the builder.
- Director controls building.
- Builder constructs object internally.
- Director calls Build() and returns the final object.
Client
|
v
Director
|
v
Builder Interface
|
v
Concrete Builder
|
v
Product (User)
Why Director Exists
Director solves an important problem:
Without Director:
Building logic may be scattered across the application.
Example:
Controller
Service
Repository
Utility classAll may create users differently.
This leads to inconsistent object creation.
Director ensures:
- Standard building process
- Reusable creation logic
- Cleaner architecture
When Director Is Useful
Director is useful when:
- Object creation has predefined configurations
- Construction steps must follow a specific order
- Multiple standard versions of objects exist
Example:
BuildAdminUser()
BuildCustomerUser()
BuildGuestUser()Why Director Is Optional?
In modern software development, the Director is often considered optional because the Client (the code using the builder) can easily take over its responsibilities.
If you look at UserBuilder code, this is acting as the Director by manually choosing which Set methods to call and in what order.
Here are the three main reasons why the Director is frequently skipped:
- The Rise of “Fluent Builders”
- Simple Object Construction
- Avoiding “Boilerplate” Code
Fluent Builder (Modern Style)
Modern C# prefers Fluent Builder, where methods return the builder itself.
In the above given approach we have these problems:
- Object creation becomes verbose as too many lines to write there.
- Construction is scattered across multiple lines and this makes it hard to readable in single flow.
To solve the problem, we can write Fluent Builder (Interface)
A Fluent Interface means:
Fluent Builder is a variation of the Builder Pattern where builder methods return the builder itself, allowing method chaining and improving readability of object creation.
Let’s make one in our example –
Builder Interface
public interface IFluentUserBuilder
{
IFluentUserBuilder SetName(string name);
IFluentUserBuilder SetEmail(string email);
IFluentUserBuilder SetPhone(string phone);
IFluentUserBuilder SetAddress(string address);
IFluentUserBuilder SetAge(int age);
User Build();
}Concrete Builder
public class FluentUserBuilder : IFluentUserBuilder
{
private User _user = new User();
public IFluentUserBuilder SetName(string name)
{
_user.Name = name;
return this;
}
public IFluentUserBuilder SetEmail(string email)
{
_user.Email = email;
return this;
}
public IFluentUserBuilder SetPhone(string phone)
{
_user.Phone = phone;
return this;
}
public IFluentUserBuilder SetAddress(string address)
{
_user.Address = address;
return this;
}
public IFluentUserBuilder SetAge(int Age)
{
_user.Age = Age;
return this;
}
public User Build()
{
return _user;
}
}Now this is a concrete implementation that returns the builder itself after each set. By using this, we can chain the SETs when calling from main code.
IFluentUserBuilder userBuilder = new FluentUserBuilder();
User user = userBuilder
.SetName("Avinash")
.SetEmail("xyz@abc.com")
.SetPhone("1234455")
.SetAddress("123 Lorem Ipsum Dolar Amet")
.SetAge(30)
.Build();See, this is more easy and quick.
Real World Examples of Builder Patterns in C#
StringBuilder
var sb = new StringBuilder();
sb.Append("Hello");
sb.Append("World");ASP.NET Core
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllers();LINQ
var result = users
.Where(x => x.Age > 18)
.OrderBy(x => x.Name);That’t it for the blog.
There are some more advanced builder patterns that we will discuss in upcoming blogs
Thanks for reading
