The Builder Design Pattern – Sequence Diagram

Last updated on 2014-09-07

The Builder design pattern is useful in two cases:

1. When you want to create a complex object and having one constructor with millions of parameters is not a good option (it NEVER is).
2. When you want to abstract the way an object is created by using different builders depending on the required task.

These are actually two very different needs. I will focus on the first type of builder, because the second kind of builder is very similar to an Factory.

In a class diagram, a builder looks like this:

yUML script:

[Client]->[Builder]
[Builder|createNewInstance();initStep1();initStep2();getInstance():ComplexClass]
[Builder]->[ComplexClass]

Flow-wise, the Builder works like this: first, we tell it that we want to build a new ComplexClass, maybe passing some initial parameters. Then we call all the steps required to build that class (initStep1(), initStep2, etc..) and when the class is completely initialized, we can request the instance from the builder. Using sequence diagrams:

WebSequenceDiagrams script:

 Client->+Builder:createNewInstance()
 Builder->-ComplexClass:complexClass = new()
 Client->+Builder:initStep1()
 Builder->-ComplexClass:step 1 initializations
 Client->+Builder:initStep2()
 Builder->-ComplexClass:step 2 initializations
 Client->+Builder:getInstance()
 Builder-->-Client:complexClass
 

I don’t specify what is done in the initialization steps called by the Builder. This is the actual work that the Builder abstracts from the client. It can be a simple method call or a long set of operations, but to the client this is irrelevant.

Last week I read about something called the Wizard design pattern, which seems an improved version of the Builder pattern. I will dig into it and post about soon.