Second link about the Builder pattern in a few days. And neither is very good, I'm afraid.
Neither seems to explain the goal correctly.
The other one, the Youtube video, pretends that the pattern helps with argument order/meaning. It's somewhat funny since they are using VSCode in their video and Intellisense is clearly telling them what each parameter is everytime they try to call a function.
This one presents the building as a very *inflexible* process. That is, it argues that various builders need to implement exactly the same methods. This would negate the most important advantage of the builder pattern: That it can accommodate building different variants of an object.
Another problem is that the examples used in both cases are inadequate. In the video because it completely misses the point. In this article because it doesn't present any complexity at all; the difference Car vs Truck is simply the value of the number of doors.
----
The truth is that the need for the builder pattern in JavaScript is fairly limited.
The problem "solved" in the video would be much better serviced by simply using named arguments, which in JS you do by using an object and is a very common idiom. The problem solved in this article is... inexistent; it solves no problem at all. It would be much better written by having something like:
function Car() {
this.doors = 4;
this.say = ...;
}
function Truck() {
this.doors = 2;
this.say = ...;
}
...and simply forgetting about the Shop and the *Builder functions.
----
What the builder pattern can help with in JavaScript is the case were you do need to build complex objects which accommodate for different variants.
That is, taking the example of the car, you might need to build various cars. A car may be a coupe or a sedan; it may have different motor configurations, styling, equipment...
You don't want client code to always contain all the specific details implied by each of those choices. Instead, you want to be able to do something like this:
const sportsCar = new CarBuilder()
.coupe()
.sportsMotor()
.colour('red')
.build();
const familyCar = new CarBuilder()
.sedan()
.electricMotor()
.build();
And in both cases you get a Car. And maybe calling coupe() only means having 2 doors, but more likely it also implies some additional setting. And choosing electricMotor() can mean something complex like doing a `new ElectricMotor()` but also installing batteries and an additional panel in the controls or whatever. And you need not do the exact same steps; you might not need to select a colour and just accept the default one.
That is what the Builder pattern is best suited for. It's also the only usage that really makes sense to apply it in JavaScript.
Second link about the Builder pattern in a few days. And neither is very good, I'm afraid. Neither seems to explain the goal correctly. The other one, the Youtube video, pretends that the pattern helps with argument order/meaning. It's somewhat funny since they are using VSCode in their video and Intellisense is clearly telling them what each parameter is everytime they try to call a function. This one presents the building as a very *inflexible* process. That is, it argues that various builders need to implement exactly the same methods. This would negate the most important advantage of the builder pattern: That it can accommodate building different variants of an object. Another problem is that the examples used in both cases are inadequate. In the video because it completely misses the point. In this article because it doesn't present any complexity at all; the difference Car vs Truck is simply the value of the number of doors. ---- The truth is that the need for the builder pattern in JavaScript is fairly limited. The problem "solved" in the video would be much better serviced by simply using named arguments, which in JS you do by using an object and is a very common idiom. The problem solved in this article is... inexistent; it solves no problem at all. It would be much better written by having something like: function Car() { this.doors = 4; this.say = ...; } function Truck() { this.doors = 2; this.say = ...; } ...and simply forgetting about the Shop and the *Builder functions. ---- What the builder pattern can help with in JavaScript is the case were you do need to build complex objects which accommodate for different variants. That is, taking the example of the car, you might need to build various cars. A car may be a coupe or a sedan; it may have different motor configurations, styling, equipment... You don't want client code to always contain all the specific details implied by each of those choices. Instead, you want to be able to do something like this: const sportsCar = new CarBuilder() .coupe() .sportsMotor() .colour('red') .build(); const familyCar = new CarBuilder() .sedan() .electricMotor() .build(); And in both cases you get a Car. And maybe calling coupe() only means having 2 doors, but more likely it also implies some additional setting. And choosing electricMotor() can mean something complex like doing a `new ElectricMotor()` but also installing batteries and an additional panel in the controls or whatever. And you need not do the exact same steps; you might not need to select a colour and just accept the default one. That is what the Builder pattern is best suited for. It's also the only usage that really makes sense to apply it in JavaScript.