Builder Design Pattern in Modern C++

DZone 's Guide to

Builder Design Pattern in Modern C++

separating the construction of a complex object from its representation

· Web Dev Zone ·
Free Resource

In software engineering, Creational Design Patterns deal with object creation mechanisms — trying to create objects in a manner suitable to the situation. The basic or ordinary form of object creation could result in design problems or added complexity to the design. Builder Design Pattern in C++ solves this specific problem by separating the construction of a complex object from its representation.

By the way, If you haven’t check out my other articles on Creational Design Patterns, then here is the list:

  1.  Factory.
  2.  Builder.
  3.  Prototype.
  4.  Singleton.

The code snippets you see throughout this series of articles are simplified, not sophisticated. So you often see me not using keywords like override, final, public(while inheritance), just to make code compact and consumable(most of the time) in single standard screen size. I also prefer struct instead of class just to save a line by not writing "public:" sometimes and also miss virtual destructor, constructor, copy constructor, prefix std::, deleting dynamic memory, intentionally. I also consider myself a pragmatic person who wants to convey an idea in the simplest way possible, rather than the standard way based on common jargon.


  • If you stumbled here directly, then I would suggest you go through What is design pattern? first, even if it is trivial. I believe it will encourage you to explore more on this topic.
  • All of this code you encounter in this series of articles are compiled using C++20 (though I have used Modern C++ features up to C++17 in most cases). So, if you don't have access to the latest compiler you can use https://wandbox.org/, which has preinstalled boost library as well.


To create/instantiate complex & complicated object piecewise & succinctly by providing an API in a separate entity.

  • Builder Design Pattern is used when we want to construct a complex object. However, we do not want to have a complex constructor member or one that would need many arguments. 
  • The Builder Design Pattern constructs a complex object step-by-step, and the final step will return the object. The process of constructing an object should be generic so that it can be used to create different representations of the same object with the help of a variety of methods.

Life Without Builders

Suppose you have to create the HTML generator using C++ then very naïve way to do it is :


A sophisticated dev will create a class with a bunch of constructor argument and method to add a child node. This is a good approach though but it may complicate the object representation.

In general, some objects are simple & can be created in a single constructor call while other objects require a lot of ceremonies to create.

Having an object with 10 constructor arguments is not productive. Instead, we should opt for piecewise construction.

Builder provides an API for constructing an object step-by-step without revealing actual object representation.

Builder Design Pattern Example in Modern C++


We are forcing users here to use a builder by making data members of HtmlElements private.

As you can see, we have declared the HtmlBuilder and HtmlElement in the same file. To do so, we need forward declaration i.e. class HtmlBuilder; as it is an incomplete type. And we cannot create the object of incomplete type before compiler parses its actual declaration. The reason is simple — the compiler needs the size of an object to allocate memory for it. Hence pointer is only way around so we have taken unique_ptr.

Sophisticated and Fluent Builder Design Pattern Example

Following is the more sophisticated example of the Builder Design Pattern organized in four different files(i.e. Person.h, Person.cpp, PersonBuilder.h PersonBuilder.cpp). 





As you can see from the above example Person may have many details like Personal & Professional. And so does the count of data members. 

In our case, there are 7 data members. Having a single class for all the actions needed to create a Person through constructor might make our class bloated and lose its original purpose. Moreover, the library user needs to take care of all those constructor parameters sequence.





Rather stuffing all those construction related APIs into Person, we can delegate that task to separate entity i.e. PersonBuilder.



Isn't the above construction looks more intuitive, natural, and plain English?

  • If you are concerned about blank methods like lives() and works(), then do not worry, it will be eliminated in optimization.
  • You can also observe that we are forcing user's to use builder rather than constructor by making the constructor private & exposing only create(std::string name) API.
  • Do not over complicate things by designing an interface or abstract classes unless you need it. I have seen this in many Builder Design Pattern Examples on Web. 

Benefits of Builder Design Pattern

  • The number of lines of code increases at least to double in builder pattern. But the effort pays off in terms of design flexibility, fewer or no parameters to the constructor and much more readable code. 
  • Builder Design Pattern also helps in minimizing the number of parameters in constructor & thus there is no need to pass in null for optional parameters to the constructor.
  • Immutable objects can be built without much complex logic in the object building process.
  • Segregating construction from object representation makes the object representation slice & precise. Having a builder entity separate provides the flexibility of creating & instantiating different objects representations.

Summary by FAQs

When should the Builder Design Pattern be used? 

Whenever the creation of new object requires setting many parameters and some of them (or all of them) are optional.

  Why do we need a Builder class when implementing a Builder Design Pattern? 

It isn't necessary but there are some benefits in doing so:
- The concern of building object should be in the separate entity as per SRP.
- The original object would not be bloated.
- Easy & maintainable code.
- Testing & understanding a constructor with many input arguments gets exponentially more complicated.

  Greatest Advantage of Builder Deisgn Pattern! 

More expressive code.
MyClass o = new MyClass(5, 5.5, 'A', var, 1000, obj9, "hello");
- Instead
MyClass o = MyClass.builder().a(5).b(5.5).c('A').d(var).e(1000).f(obj9)
- You can see which data member is being assigned by what & even change the order of assignment.

If you are interested in receiving such articles directly into your inbox, please sign up to my newsletter
c-and-cpp, cpp, cpp11, cpp17, design pattens

Published at DZone with permission of Vishal Chovatiya . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}