Design patterns: Builder, Fluent Interface and classic builder

In this lesson about the Builder design pattern, or rather two of its types, which apply to the way of creating a class object, and creating an object from other objects. More details in the article.

 

Description and implementation way

The goal of the builder is to separate the way the object is created from its representation. So the process of creating an object is divided into several parts.

First, I will show an example of a builder pattern on the basis of Fluent Interface, then a classic builder.

The Fluent Interface builder should implement when the constructor has more than four or five parameters, we create a builder class, inside this class, which has this constructor with these many parameters.

Examples in which Fluent Interface Builder would be applicable are everywhere where we have constructors that take many parameters, and Classic Builder, for example in software that accepts any input data, converting it and based on input data, creates output data, i.e. in some game where, under the influence of the user’s actions, the game performs specific events, the builder will be here the code that creates specific events in the game depending on the user’s choices.

 

Builder Fluent Interface

However, we will refer to our example of the Shop, there was such a Client class:

We are adding a few other variables such as customer’s address, street, house number and city:

It does not look very clear, when we will use the fluent builder here, not only will it be much more readable, but we will also have a separate process of creating customer data from manipulating, representing them if we want to do something with this data later, so now we implement a fluent builder here the method shown below:

As you can see, we have separated the saving of customer data from the rest of the logic, and we can control to a greater extent how the object is created.

Also saving data in the “Main” function is much more readable:

Now you can see what data is saved to the object.

Result:

This is the Builder Fluent Interface, now we’ll do the example of a classic builder.

 

Classic Builder

Structure

First, let’s see what the UML Builder diagram looks like:

Scheme of Builder

Converter class as you can see, creates instances of individual classes that read different data formats, and here the Reader class is a client who only reads these formats.

An example of a builder can be eg a customer who orders food from a restaurant, look at the picture below:

Example of Builder

First, the customer orders a meal, then the report comes to the manager, who then tells the employees who later execute the order together with the delivery to the house. In the code, we will make an example of our store.

 

Example

Let’s build our store, let’s separate its objects, eg in this way walls, roof, floor, what will it look like in a classic builder?

An example may start a fright at the beginning, but it’s really a simple pattern, you just have to convert it into practice.

I will translate pieces of the whole code one by one, I will give the whole example at the end of the lesson in the source files, because it is long.

The classic builder can be treated as a plan.

The diagram of the created store looks like this:

We add to the Shop class, roof, floor, and wall, then create a store object with the manager in the client, in our case in the Main function, the whole is designed so that the customer can’t see how the store is created, client is commissioning the build shop the builder so relating to our example, Director class, and the client does not care how the store is built, only the finished product is delivered to him.

Let’s see now how it looks in the code, let’s start from the left side of the diagram, ie the Shop, Roof, Floor, Wall classes:

Shop:

Floor:

Roof:

Wall:

We implement its elements in the shop class, but in the form of interfaces, we stick to the fifth SOLID principle, dependency inversion, class relations should result from abstraction and high-level modules should not depend on low-level modules, the store is a high-level module and the roof, floor, wall they are low-level modules, such a small reminder on the SOLID principles 🙂

Our builder looks like this:

Is an interface that we implement to the store class we want to build and we want to build a large Tesco store 🙂

It looks like this:

We set in methods the BigShopTesco class parameters sets its elements and write them to the interfaces of the Shop class.

We call the BigShopTesco class methods in our manager, in the ShopDirector class:

To the constructor of the ShopDirector class we pass the object of the class that we want to create, that is BigShopTesco and we call its methods.

And from the client’s side it looks like this:

As you can see, the customer does not see how the store is built, and so it should be him does not care about it, he just orders the manager.

At the end of the lesson I will give the source code to this builder.

Remember, nonsense is just a read, to understand it is best to create your own builder, you can help yourself that what I did to make my own builder. You will not understand it without practice.

In both cases you should use Builder wisely, because when we have a lot of these builders, the code becomes unreadable.

Result:

 

Advantages and disadvantages

Advantages

  • High scalability (creating new data is easier)
  • More control over how the object is created (The process of creating the object is independent of its other representations)
  • Better readability (with proper use 🙂)
  • Large diversity of class interiors.

 

Disadvantages

  • A large number of objects
  • Improper use of this pattern may cause the code to be unreadable (one object may contain too many builders)

 

Relations with other patterns

  • Builder is often used with the Bridge pattern, Director is an interface and the builder is in the implementation role.
  • The builder is used with the Composite pattern to create a tree.
  • Patterns The Abstract Factory, Builder and Prototype can be implemented as Singletons
  • Often, the Builder’s implementation is combined with an Abstract factory to maintain flexibility and not create concrete types of classes.

 

Summary

This long lesson came out, but it’s probably good because the builder was hopefully well explained.

That’s all about Builder.

Link to github with the whole code from this article:  https://github.com/Slaw145/BuilderTutorial

This content also you can find on my steemit blog https://steemit.com/design-patterns/@slawas/design-patterns-builder-fluent-interface-and-classic-builder

And on medium: https://medium.com/@sawomirkowalski/design-patterns-builder-fluent-interface-and-classic-builder-d16ad3e98f6c

In the next article, we will talk about the Abstract Factory pattern.

As a standard, I remind you about the newsletter, which I send notifications about new entries and additional information about the IT world in general.🙂

And NECESSERILY join the DevmanCommunity community on fb, part of the community is in one place 🙂

– site on fb: Devman.pl-Sławomir Kowalski

– group on fb: DevmanCommunity

Ask, comment underneath at the end of the post, share it, rate it, whatever you want🙂.

 
If that post was useful for you share it with your friends :)

Post a comment

Be first!

avatar
  Subscribe  
Notify about