The Builder design pattern is a creational design pattern which lets us create an object one step at a time. It is quite common to use this pattern when creating a complex object. By using this pattern, we can create different parts of an object, step by step, and then connect all the parts together.

Without this pattern, we can end up with a large constructor to provide all the required parameters for constructing our object. That could lead to quite unreadable and hardly maintainable code. Furthermore, a constructor with lots of parameters has a downside to it. We won’t need to use all the parameters, all the time.

In this article, we are going to show you how to implement the Builder pattern to avoid such complex constructors. We will go even further and explain the Builder Recursive GenericsBuilder Recursive Generics design pattern and Faceted Builder design pattern as well in our next articles.

You can download the source code from here: Builder Design Pattern – Source Code

This article is divided into the following sections:

Implementing the Builder Design Pattern

We are going to write a simple example of creating a stock report for all the products in our store.

So, let us start with a simplified Product class:

We are going to use this class just for storing some basic data about a single product.

Our stock report object is going to consist of the header, body and footer parts. So, it is quite logical to divide the object building process into those three actions. First, let’s start with the ProductStockReport class:

This is the object, we are going to build with the Builder design pattern.

To continue on, we need a builder interface to organize the building process:

We can see that the concrete builder class which is going to implement this interface, needs to create all the parts for our stock report object and return that object as well. So, let’s implement our concrete builder class:

This logic is quite straight forward. We receive all the products required for our report and instantiate the _productStockReport object. Then, we create all the parts of our object and finally return it. In the GetReport method, we reset our object and prepare a new instance to be ready to create another report. This is usual behavior but it is not mandatory.

Once our building logic is over, we can start building our object in a client class or even encapsulate the building process from the client class inside a Director class. Well, this is exactly what we are going to do:

Creating  the StockReport Object

After we have finished all this work, we can start building our object:

The result :

Builder Design Pattern - Result

Excellent. We have created our object with the Builder design pattern.

Fluent Builder

The Fluent builder is a small variation of the Builder design pattern, which allows us to chain our builder calls towards different actions. To implement the Fluent builder, we are going to change the builder interface first:

We have to modify the implementation of the ProductStockReportBuilder class as well:

As a result of these modifications, we can chain the calls in the Director class:

If we start our application now, the result is going to be the same, but this time we use the fluent interface.


In this article, we have learned about how to create Builder Design Pattern and how to implement it into our project to create complex objects. Furthermore, we have expanded our example to use the Fluent interface, which allows us to chain our Builder calls together.

In the next article, we are going to learn how to implement Fluent Builder Interface With Recursive Generics.

If you have enjoyed reading this article and if you would like to receive the notifications about the freshly published .NET Core content we encourage you to subscribe to our blog.