Builder Pattern of Creational Design Patterns for .Net Core
Problem:
Let’s assume that there is more than one subscription type in our application as in the image. We need to make different calculations according to the choices made by the customer.
Along with different subscriber types a variable calculation depending on the monthly or annual selection makes the event more and more complex.
A new package may arrive in the future. Or we can say that there may be changes in the calculations on the package.
For the premium account, we see that the customer goes to a different place in the other subscription calculations that we have optionally selected how many users they want to manage in the system.
Solution :
We will solve this problem with the Builder Pattern. Each subscription type will be able to calculate on its own but none of them will be called directly. We will have a director who manages subscription accounts.
Before our director takes office the relevant builder will be assigned to him and he will lead us to create all subscription types by providing access to his methods.
Thus on the code side, we will manage issues such as what we will value and what we will calculate in a healthier way. It will be both expandable and readable design.
Let’s move forward by giving some examples from the classes included in the project. For a detailed review, I will be sharing the github repo link at the end of the article.
First we created our model called “SubscriptionPackage” which will be used by all creators. This model contains methods that can change all the features in it.
I created our interface called “IPackageBuilder” where values such as “number of users, storage value, unit price” that we see in the image will be set.
We will require a package generator included in the subscription system to implement all the methods we specify.
Thinking that we will have more than one subscription structure, I am creating a basic method for builders. I have all builders build by inheriting from “BasePackageBuilder”.
While doing set operations in the base method, I actually use the set methods on the domain(SubscriptionPackage). Thus I allow the domain to decide its own rules by following the DDD rules.
Each creator will get their own SubscriptionPackage and set the values as determined by the director. We could do without creating separate classes for each subscription type, but there may be future differences between the constructors.
For now although there is a different calculation according to the number of users in Premium subscription type in our example, this value is always the same in others. I have created separate classes to be flexible in such situations.
Since each generator will inherit from the base class, it will be free to set the desired value by crushing the methods from the base class for different calculations unique to itself.
When you open the project you will see that all classes except PremiumPackageBuilder do nothing but the methods from the base class.
For PremiumBuilder we need to make a different calculation according to the change in the number of users.
Don’t get hung up on the formula here, I set a random formula myself.
In each constructor we change the set unitPrice value by overriding the “SetUnitPrice” method from the base class here. When you browse the Base class, it calculates the “totalPrice” value with a method like “unitPrice*12”.
Naturally when we change the “unitPrice” value, we can continue our process without making any changes in the “totalPrice” method. In this method after dividing the number of requested users by 1000, I multiplied by the existing unit amount and completed the process by making -1.
As I said don’t get hung up on the formula here. This subscription may vary depending on the analysis you have made on your system. You can calculate differently for all other builders, not just PremiumBuilder.
Finally we came to the point where the default values of the subscription packages will be set by whom. The builder will say I don’t know value or anything. I will do my part and finish the job.
It should be like this anyway, it will give it the necessary values “PackageDirector”. It will also be the only class we are in contact with for creating the requested subscription package.
The method we request after the builder we assign to the Director is our responsibility. If we go to Director and set “FreePackageBuilder” and ask for premium calculation, we will not get the correct result. If we want to make obstacles in this way, we can decide this within the director.
For example, if the “BuildFreeMonthlyPackage” method is called but the “IPackageBuilder” sent is not “FreePackageBuilder”, we can fire an exception. If you want to make an example of this, please stay in touch.
Values such as “unit price, number of users” that we give to the creators are static. Of course we will have to make them dynamic. For now I chose this way in order to progress faster in sampling.
Let’s take a look at what results we got.
Request : Monthly payment subscription information
Request: Premium subscription package information with 5k, 10k and 15k users
In the result screen, we can see that the annual amounts are more appropriate. We have obtained values close to the image at the top of the page. As I said the formulas are up to you.
We have achieved our intended result. With BuilderPattern, we can calculate for more than one subscription package.
Repo URL : https://github.com/gsmtcnr/DesignPattern.Creational.BuilderPattern
Yazının Türkçe kaynağı :
http://www.sametcinar.com/builder-pattern-of-creational-design-patterns-for-net-core/
