Superb lecture. I saw 2-3 other youtube channels for understanding builder patterns. Many tried but were not clear due to bad examples, difficult code walkthrough. What separated this video from Yogita is that she explained the painful areas of non-builder pattern based examples, she explained a technical jargon of constructor telescoping, the examples made great sense, two example codes to make the understanding crystal clear. @Yogita Thank you so much
Mam your way of teaching is just so amazing..it gives an extra view to see the code and to understand the code in easiest way.grateful that i found you
what a nice value addition to my engineering life. I am enjoying watching the design pattern playlist. It's above par comparing to any paid courses. Thanks a lot ....
Hi Yogita, can you please upload the code online and share the code url in the description. So that we can also try manipulating the code for the given design pattern.
This is a good introduction into the Builder pattern but it misses a few things. How about making sure that required fields are actually enforced in the code? Right now nothing is stopping you from building the URL that contains only 'path' and 'query' parameters but is missing the protocol/hostname part.
7:41 People probably wonder why create a new object based on an existing static object instead of only using one? In other words: Why going through the hassle of a static Builder, private constructor and _new_ in URLBuilder.build() instead of just populating the _new_ in Demo.main()? The answer is immutability. And although it's not needed in this particular example, it's a clever example to follow in other situations.
Thank you for your efforts to deliver such great explanation and helping us understanding the weird parts about design patters however, I do have a question mark about using nested class why we had to use nested class instead of using sole abstraction builder class or interfaces?
What if we try to make it un-immutable. I removed final from fields and then created getter and setters as well to make it un-immutable. I don't see any issue. If any?
Doesn't the objects still have other optional fields with value null? Its just like using a constructor with all params . Does it just helps to remove the extra nulls ,that we need to pass to the constructor, with all the params?
I have a question. Here we create two classes: URLBuilder and Builder and after coding the logic we called the constructor for URLBuilder and passed the Builder class object as a param. Why dont we make 1 class called URLBuilder and implement the same logic for each part of the url and for every part return the same object whose attributes we set(like we did in builder). We are going to create an object for the URLBuilder and for builder might as well create one class and from it create multiple instances or urls here. Is it cuz of abstraction or providing some depth as in layers to code or what?
Thanks for such a nice explanation. I have a doubt. Why are we using a static inner class in the builder design pattern? Can't we use a normal inner class? or can we do it without inner class?
Thanks! I just have one question. Why use inner static class here? Why can't we have those constructors directly in URLBuilder instead and chain individual constructors that return type URLBuilder?
Yes, I too tried so and it worked. Just fields and then field method which return object itself. Moreover, I removed final from fields and then created getter and setters as well to make it un-immutable. I don't see any issue? You found any ans?
I didnt understand one thing in builder pattern. What if we need to add another attribute to the static builder class like price? Do we need to modify the static class? How will we implement it?
One correction: builder.build() call should actually return the URL object instead of the builder object. This builder object is part of the URL object constructor such that the value set in the builder could be used to construct the URL object. Am I missing something ?
Hey Yogita. Huge fan of your video, crisp and easy to understand. For this (builder pattern) implementation, saw some other sites as well, seems like 1. using inner nested class is not the only to implement it. People are using combination of (interface and abstract classes to achieve the same). 2. In your implementation isn't the code duplicated, as in the UrlBuilder and Builder class, you are writing the same fields again. Looks a bit messy. Dont you think?
You have created object of static class Builder, which seems strange here... Same thing when I am trying to implement in typescript I am getting "Error"
But at last after using builder design , the URL class is of no use? what i mean to say is , we should be able to print url.protocol , instead of urlBuilder.protocol.
Thank you for providing such good videos. I have a question how is builder pattern advantageous than just having default constructor without parameters and calling setter function to initialise attributes.
Imagine you have 10+ params and you just need to create objects with 2-3 values set. You will have to write null in all unwanted params place. (extra work) Imagine you need to create multiple similar objects. (unwanted code, extra work) Builder pattern to the rescue
First of all thanks a lot for this series, learning a lot from it. I have one doubt, in build method we are hardcoding URLBuilder class. Can we somehow use factory pattern along with builder pattern to create the URLBuilder object? so that in future, if I need to create TinyURLBuilder or any other object I can do it with minimal changes
You did not explain why we can't use setters only? Yes, the code looks redundant but I would have liked some explanation over it. Moreover, @Builder annotations for classes allows its objects to be modified.
Yes I used setters and getters and then removed the final as well to make it un-immutable and it does work. I didn't get what's the problem in doing so? If anyone please let me know?
I saw a couple of videos for builder patterns but this is really crisp and useful. Great, keep 'em coming.
Loved the design pattern series. I understood this in a single go. 😊
Superb lecture. I saw 2-3 other youtube channels for understanding builder patterns. Many tried but were not clear due to bad examples, difficult code walkthrough. What separated this video from Yogita is that she explained the painful areas of non-builder pattern based examples, she explained a technical jargon of constructor telescoping, the examples made great sense, two example codes to make the understanding crystal clear.
@Yogita Thank you so much
This is the best explanation I have ever went across for Builder Pattern. Thanks a lot for your work, really grateful to you !!
Mam your way of teaching is just so amazing..it gives an extra view to see the code and to understand the code in easiest way.grateful that i found you
what a nice value addition to my engineering life. I am enjoying watching the design pattern playlist. It's above par comparing to any paid courses. Thanks a lot ....
The way u organize the course is nice. This is a simple design pattern which lacks the concept of OC principle.
Best ever video I've seen so far on design pattern
Hey Yogita,
You have explained this in very simple way, with practical example.
Really liked your work.
In office I was writing code this way all along...just by following/understanding already written code... Never knew I was utlising Builder pattern
Best series on design patterns please complete rest as well
Finally in forever i understood this concept!!
superb example and explanation, understood in few minutes
One of the best explanation on builder design pattern!!
Refactoring has become very easy in this pattern with some cons to use according to usecase.
Thanks for video.
Such a crisp and easy-to-follow video. Thanks for making this... :)
Wow!! You are such a good teacher.
Very simple and easy to understand , thank you for the design patterns series.😊
It's worth mentioning that C++ and C# (at least) simplifies all the charade to nothing by use of optional parameters.
It does. But builder pattern is worth to use when each component creation is complex.
Hi Yogita, can you please upload the code online and share the code url in the description. So that we can also try manipulating the code for the given design pattern.
Loving whatever content you are creating. Most easiest ways you try. Much appreciated. Thank you so much _/\_ _/\_
This is a good introduction into the Builder pattern but it misses a few things. How about making sure that required fields are actually enforced in the code? Right now nothing is stopping you from building the URL that contains only 'path' and 'query' parameters but is missing the protocol/hostname part.
7:41 People probably wonder why create a new object based on an existing static object instead of only using one? In other words:
Why going through the hassle of a static Builder, private constructor and _new_ in URLBuilder.build() instead of just populating the _new_ in Demo.main()?
The answer is immutability. And although it's not needed in this particular example, it's a clever example to follow in other situations.
Because we need to use encapsulation to hide complexity of the code and for isolation
Thank you for your efforts to deliver such great explanation and helping us understanding the weird parts about design patters however, I do have a question mark about using nested class why we had to use nested class instead of using sole abstraction builder class or interfaces?
I have the same question.
What if we try to make it un-immutable.
I removed final from fields and then created getter and setters as well to make it un-immutable. I don't see any issue. If any?
Thanks for the upload ..Great....Please Complete all Design Patterns.. 🙂🙂
Doesn't the objects still have other optional fields with value null? Its just like using a constructor with all params . Does it just helps to remove the extra nulls ,that we need to pass to the constructor, with all the params?
I have a question. Here we create two classes: URLBuilder and Builder and after coding the logic we called the constructor for URLBuilder and passed the Builder class object as a param. Why dont we make 1 class called URLBuilder and implement the same logic for each part of the url and for every part return the same object whose attributes we set(like we did in builder). We are going to create an object for the URLBuilder and for builder might as well create one class and from it create multiple instances or urls here. Is it cuz of abstraction or providing some depth as in layers to code or what?
Beautifully explained! Subbed, Thank you!
Thanks for such a nice explanation. I have a doubt.
Why are we using a static inner class in the builder design pattern? Can't we use a normal inner class? or can we do it without inner class?
Thanks! I just have one question. Why use inner static class here? Why can't we have those constructors directly in URLBuilder instead and chain individual constructors that return type URLBuilder?
Yes, I too tried so and it worked. Just fields and then field method which return object itself.
Moreover, I removed final from fields and then created getter and setters as well to make it un-immutable. I don't see any issue? You found any ans?
I didnt understand one thing in builder pattern. What if we need to add another attribute to the static builder class like price? Do we need to modify the static class? How will we implement it?
One correction: builder.build() call should actually return the URL object instead of the builder object. This builder object is part of the URL object constructor such that the value set in the builder could be used to construct the URL object.
Am I missing something ?
@francescovanspronsenyes, u can even rename the class UrlBuilder to just Url. In that case u ll get what u r looking.
Hi, why can't we use default constructor along with setters to set the value of field instead of making constructor for every param
how can you create an instance of the inner static class Builder ?
Hey Yogita. Huge fan of your video, crisp and easy to understand.
For this (builder pattern) implementation, saw some other sites as well, seems like
1. using inner nested class is not the only to implement it. People are using combination of (interface and abstract classes to achieve the same).
2. In your implementation isn't the code duplicated, as in the UrlBuilder and Builder class, you are writing the same fields again. Looks a bit messy. Dont you think?
It would be very helpful if we could get the code for the same as it helps in grasping the concept even better.
Thanks for the wonderful and easy explanation
Clear and precise!
Awesome Explanation!! Great example use.
You have created object of static class Builder, which seems strange here... Same thing when I am trying to implement in typescript I am getting "Error"
Very eazy to understand and simple & clean example. Loved it!!
[1,2,3,4,5].map(d=>d*2).filter(d=>d
This is really a very good video, thank you mam for creating such good videos.
But at last after using builder design , the URL class is of no use? what i mean to say is , we should be able to print url.protocol , instead of urlBuilder.protocol.
Exactly, this is seriously misleading. I'm really surprised to see how this could've helped so many of these people commenting here.
Superb Explanation..
Thank you for providing such good videos. I have a question how is builder pattern advantageous than just having default constructor without parameters and calling setter function to initialise attributes.
Firstly we want do not want to use the new keyword(which Factory pattern solves) and second we use builder pattern to make objects immutable.
Thanks for easy explanation
Hi, wanted to know why can't we use default params in constructor as null to resolve unwanted fields in class in this case?
We can it makes the code cumbersome and lengthy for no reason.
Imagine you have 10+ params and you just need to create objects with 2-3 values set. You will have to write null in all unwanted params place. (extra work)
Imagine you need to create multiple similar objects. (unwanted code, extra work)
Builder pattern to the rescue
Very good. Keep it up.
Thanks a lot
First of all thanks a lot for this series, learning a lot from it.
I have one doubt, in build method we are hardcoding URLBuilder class.
Can we somehow use factory pattern along with builder pattern to create the URLBuilder object?
so that in future, if I need to create TinyURLBuilder or any other object I can do it with minimal changes
Yes, u can implement multiple patterns together
Thanks allot, I am learning a lot.
You did not explain why we can't use setters only?
Yes, the code looks redundant but I would have liked some explanation over it.
Moreover, @Builder annotations for classes allows its objects to be modified.
Yes I used setters and getters and then removed the final as well to make it un-immutable and it does work. I didn't get what's the problem in doing so? If anyone please let me know?
If there's no need of immutable object, then there are alternatives to builder. But immutability is a good thing specially in a threaded env.
Great Video
nicely explained
PLZZZ SHARE THIS PROJECT GIT LINK
Loved it
Easy peasy
Yeh transition bahut bakwas hai
I hope you find peace of mind and freedom from whatever is bothering you in life.
𝐩𝓻Ỗ𝓂Ø𝓈Ｍ