Builder Design Pattern

In the earlier tutorials we have seen the factory method and the abstract factory pattern. In this tutorial we look at another creational pattern called the Builder Design pattern.

The Builder Design pattern specifies a builder class that creates multiple objects in a step by step manner. The client uses the builder to build the multiple objects and is itself not concerned with how or which object is created. The client has reference to the interface of the objects created and not the actual implementation. The factory method delegated the object creation to a subclass, the abstract factory pattern provided a factory using which the client can create multiple objects, and the Builder pattern goes a step further in that the client does not have to concern itself with creating the objects. We will use the same Car Builder example to understand the builder pattern.

We design a framework that can build cars. The Car consists of a body type, an engine type, an insurance plan and a maintenance plan. The aim of the pattern is to design in such a way that the client can be used to create multiple cars without worrying about creating the body, engine, insurance and maintenance objects

Lets first look at the various classes

We define a Car interface that has setters for Objects that build it. We have implemented a Ferrari car. Note that the setters take an interface an not a concrete implementation.

The Insurance Interface is implemented by two kinds of insurance schemes, partial and complete.

The Maintenance is defined as an interface and implemented by two types of maintenance schemes, basic and comprehensive.

The BodyType is defined as an interface which is implemented by a convertible and a sedan.

We define two engine types, V4 and V6

We code to interfaces since then its possible to add more implementations. Lets look at how we would do this in a non design pattern world. The client creates an instance of a car. It then creates instances of each object (Body Type, Engine Type, Insurance and Maintenance) and assigns it to the car.

Lets look at the problems in this approach and how Builder Pattern can solve them

  • The client needs to know how to build the cars. If there is a change in the way a car is built then all the clients would need to implement the change (If an insurance policy changes then all clients have to change their code). The Builder pattern solves the problem by delegating the process of creating the objects in a separate class. The Builder class not only creates the objects but also makes sure that they are created in a specified order
  • We can use the abstract factory pattern, but the number of combinations can increase at a fast place and we would end up with lot of factories. We can design a Builder that can take in a list of initialization parameters and create the required objects in a step by step fashion.

Hers’s a class diagram using the Builder Pattern.

Bridge Design Pattern

The classes


The Client

Here’s an explanation of the classes

CarBuilder – The CarBuilder is the builder that is the heart of this pattern. Its job is to create the objects that form part of the car. Our Builder has two methods, or two ways to instantiate car objects. The first method called buildCar creates the objects using a predefined sequence and type. The second method is a parameterized builder. We pass in multiple Strings. Each string defines the type of object to be created. For example, “bodyType-sedan-mazdasedan” creates a BodyType Sedan named mazdasedan. The advantage of the parameterised builder is that the client can specify the concrete type to be created and also the sequence in which they should be created

CarBuildClient – The Client describes how the builder can be used. We create the objects for Ferrari using the FerrariCarBuilder and the Mazda using parameterized method of MazdaCarBuilder.

Lets see the advantages of the builder method

The client does not need to know which concrete implementations to create or the order in which they are created. The pattern encapsulates the object creation and order from the client.

New Builders can be added without modifying any existing classes. Current Builders can be modified. The clients do not have to change any code.

The design codes to interfaces and not to concrete implementations. The product (Car) and the builder(CarBuilder) hierarchy can be evolved independently

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.