Sinking into Design Patterns

Builder

As I discussed in a previous blog Design Patterns are commonly found ways to approach specific problems. Today I bring to you the Builder design pattern, one of the creational type design patterns. The idea behind the design pattern is to construct complex objects step by step that produce different types and representations while using the same construction code.

The Problem that it is try to solve is creating complex objects with many initializations of many different fields and nest objects. Many times when people create objects they create them with the intention of a few parameters that may change out. Like an music album, which has an artist, tracklist, genre, artwork, etc. Well when you try to apply a model for all of the different kinds of bands that exists, you start to run into having to create subclasses to represent an electric bassist versus a cellist in an orchestra band. Your parameters end up getting messy.

The Solution is to extract the object’s construction code out of itself and move it into separate objects that are called builders. These individual builders focus on only on what you need instead of what you don’t need. So if we take our band example a step further we create models that do the building of the band step by step( buildSinger, buildDrumer, buildBassists, etc etc.)

Each of these builders has a specific step for coming together to build a Band object, but no band needs to be one of the same as the other. You can even have certain builder objects that build same set of steps but in a different manner, kind of like the subtle differences between a Lead Guitarist and a Rhythm Guitarist. You can continue going further with this by creating a director. The director will tell the other classes which in which order they should be built as and the implementation for those steps.

1. The Builder interface declares product construction steps that are common to all types of builders
2. Concrete Builders provide different implementations of the construction steps. Concrete builders may produce products that don’t follow the common interface
3. Products are resulting objects. Products constructed by different builders don’t have to belong to the same class hierarchy or interface
4. The Director class defines the order in which to call construction steps, so you can create and reuse specific configurations of products
5. The Client must associate one of the builder objects with the director. Usually, it’s done just once, via parameters of the director’s constructor. Then the director uses that builder object for all further construction. However, there’s an alternative approach for when the client passes the builder object to the production method of the director. In this case, you can use a different builder each time you produce something with the director

The way you should implement this pattern is when you have classes with multiple parameters. Once you start exceeding 10 parameters this could help start giving some other approaches on your class.

When implementing make sure have clearly defined construction steps. The steps have to be clearly declared in the builder interface. You have to create concrete builder classes for each item you’re hoping to represent. As an optional take you can think of a director class for when you want construct a class with different builders.

Be sure to way your options prior to this, it can increase the complexity of the code since you’ll be creating new classes each with instructions that are needed.