Builder Design Pattern

Introduction: The Builder Design Pattern helps us to slice the operations of building an object. It also enforces a process to create an object as a finished product. That means an object has to be massaged by some instructed steps before it is ready and can be used by others. The massage process could apply any restrictions or business rules for a complete building procedure (or a procedure we follow to make an object that is considered as a ready to use object). For instance, to compose an email, you can’t leave the To and Subject fields blank before you can send it. In other words, an email object will be considered as an uncompleted email object (a common business rule for email) if those two fields are not filled. It has to be built (filled) before we can send it out.

The Builder Design Pattern allows you to create a general guideline on how to create an object, then have different implementations on how to build parts of the object.

There are two principles in the Builder Pattern; let’s use an example of building an airplane to demonstrate the features:

• The first principle is the general guideline that must be followed when building an object. For example, in building an airplane, the body must be constructed before the wings. This general guideline must be followed regardless of what type of airplane you are building.
• The second principle are the different specifications on building the parts of the airplane. When building a jet airplane, the body must be built differently than a propeller airplane. These specifications are included in the pattern. 

With these two principles in place, let’s look at the UML of the Builder Pattern using the example of building an airplane:

The Director class contains the logic of the general guideline. In this case, its BuildAirplane method would specify that an airplane body must be built before the wing. Therefore the code for theBuildAirplane method would be:

public Airplane BuildAirplane(IManufacturer m)      
{         
    m.BuildBody();  //we build the body first
    m.BuildWing();  //then we build the wing
    return m.GetProduct();
}

• The IManufacture interface specifies the methods that all airplane manufactures must support. We see that it must be able to build the airplane body with the BuildBody method and build the wing with theBuildWing method. The GetProduct method just returns the product that is being built, which is the airplane.
• The Manufacture class is the concrete manufacture class that has the implementation on building the parts of an airplane, hence it implements the IManufacture interface and holds a reference to theproduct variable, which is the airplane that is being built.
• The Airplane class is just the final product being built.

With the Builder Design Pattern in place, the client code (calling code) to build an airplane will just be:

Airplane a = director.BuildAirplane(new Manufacture());

The Builder Pattern allows you to create different concrete airplane manufactures that specify how the parts of the airplane are constructed. You can then pass in any manufacture to the director and it will build the airplane according to the specifications without having to change the client code.

The key to the Builder Pattern is that:

• You only need to determine the sequence in which the product (the airplane) is constructed in theDirector.
• You can have different implementation of the manufacturers on how the parts of an object (the body and the wings) are constructed.

The benefit of the Builder Pattern is that you can swap out any implementation on how the parts are built by changing the manufactures, and the rest of the client code will not need to be changed.

In application frameworks today, we often see the Builder Pattern being utilized. For example, you may have multiple configuration files that have information on database services, file location services, and notification services. These configuration files would be your manufactures, where each have their own specifications on how each part of the configuration object should be built. The director would specify the way to read the configuration file, for example, you may need to read the database services first before you read the notification services.