Hi, I'm a developer with three year of experience. I am trained in Java/J2e but I am mostly a Javascript/Typescript lover <3 currently working in GIS, with ReactJS and LeafletJS
Interesting, in fact, I am in some way in both case. I have an API that send JSON, with many properties (like 12 properties or more) that I must convert to an object. The results will have to be manipulate to send back another object (in a different form). So both use case can happen.
But what about the critics that I read many times, about the fact that adding all those class makes the code less efficient? a waste of resources, some says ?
I haven't done much research on the criticisms of the builder pattern. But I am interested in exploring the arguments presented by these critics. I'd appreciate it if you shared an article or video link with me that discusses in detail the critics presented on this pattern so I can read these criticisms and make up my own mind.
That said, at least on the surface, I don't see how the use of the builder pattern could be a waste of resources or ... a way of making code less efficient. At least, if you're speaking in terms of the performance of your application. I don't think the use of the builder pattern or any other pattern in structuring your code could affect the speed of your code in any way that is significant if your code is running on modern technology.
The only criticism I can think of, that in my opinion, would be valid right off the bat, is if you're overusing the builder pattern or making use of builders in scenarios that really don't require it. Because it does include an extra layer of complexity.
By extra layer of complexity I mean... when someone is reading through your code, if they come to a point where an object is being created by your builder, they'd have to take the time to understand both the Builder class and the main class i.e both AthensCarshopBuilder and Carshop.
In the absence of the builder class, the only thing they'd have to bother about understanding would be the Carshop class. So the fact that a developer going through your code would need to understand 2 things instead of 1 thing in order to get something done (like make a modification to your Carshop class), is an added complexity. This increased complexity will make it harder for someone else... even perhaps yourself a few months later, to understand and work with your code. The harder the code is to understand, the harder it is to get things done in it... so at least, in terms of developer productivity, I think the overuse of the builder pattern, or frankly, any code design pattern at all, can be a disadvantage.
But like I said, if you have links to other arguments on this issue, I'd like to read through them and share my thoughts on them.
Hi, I'm a developer with three year of experience. I am trained in Java/J2e but I am mostly a Javascript/Typescript lover <3 currently working in GIS, with ReactJS and LeafletJS
Interesting, in fact, I am in some way in both case. I have an API that send JSON, with many properties (like 12 properties or more) that I must convert to an object. The results will have to be manipulate to send back another object (in a different form). So both use case can happen.
But what about the critics that I read many times, about the fact that adding all those class makes the code less efficient? a waste of resources, some says ?
I haven't done much research on the criticisms of the builder pattern. But I am interested in exploring the arguments presented by these critics. I'd appreciate it if you shared an article or video link with me that discusses in detail the critics presented on this pattern so I can read these criticisms and make up my own mind.
That said, at least on the surface, I don't see how the use of the builder pattern could be a waste of resources or ... a way of making code less efficient. At least, if you're speaking in terms of the performance of your application. I don't think the use of the builder pattern or any other pattern in structuring your code could affect the speed of your code in any way that is significant if your code is running on modern technology.
The only criticism I can think of, that in my opinion, would be valid right off the bat, is if you're overusing the builder pattern or making use of builders in scenarios that really don't require it. Because it does include an extra layer of complexity.
By extra layer of complexity I mean... when someone is reading through your code, if they come to a point where an object is being created by your builder, they'd have to take the time to understand both the Builder class and the main class i.e both AthensCarshopBuilder and Carshop.
In the absence of the builder class, the only thing they'd have to bother about understanding would be the Carshop class. So the fact that a developer going through your code would need to understand 2 things instead of 1 thing in order to get something done (like make a modification to your Carshop class), is an added complexity. This increased complexity will make it harder for someone else... even perhaps yourself a few months later, to understand and work with your code. The harder the code is to understand, the harder it is to get things done in it... so at least, in terms of developer productivity, I think the overuse of the builder pattern, or frankly, any code design pattern at all, can be a disadvantage.
But like I said, if you have links to other arguments on this issue, I'd like to read through them and share my thoughts on them.
You can read some in the comments of that article :
4 Dangerous Problems in JavaScript Easily Solved by The Builder Design Pattern
jsmanifest ・ Nov 25 ・ 12 min read
and in the comments of this one :
Builder Design Pattern
Nishan Pantha ・ May 28 '17 ・ 2 min read
This article on Kotlin :
Avoiding the Builder Design Pattern in Kotlin
Christian Vasquez ・ Jan 5 '18 ・ 3 min read
One for Java :
When Builder is anti-pattern
Sergiy Yevtushenko ・ Nov 5 ・ 2 min read
With so many different point of view, it can get confusing.