For people like me that are confused by the explaination at the beginning, here is another that should be easier to understand: You are in a Cookie Factory. Machines make the dough (the Data) for the cookies, but the dough doesnt have any form yet. You need cookie cutters (the Builders) to bring them in form. You can use many different cutters to get a different form for your cookies, like a normal round form, a star form and whatever form you can imagine. It doesnt change the ingredients of the dough, just its representation. I hope this helped some people :/
@RawCoding3 жыл бұрын
Great example!
@manishpandey46212 жыл бұрын
You are my Hero! If ever there was one Teacher/mentor I wanted, you are the one! This video showed how we can envision a product when we code.... thanks!
@RawCoding2 жыл бұрын
thank you for the kind words
@Вадим-э4х8ш2 жыл бұрын
Для изучения языка решил послушать про известные мне паттерны на английском. И на тебе - красная Лада!))
@RawCoding2 жыл бұрын
🚗...
@saurabhchauhan2323 жыл бұрын
Finally All this happening as said earlier that will do this in future, time has come. Thank you Anton sir
@RawCoding3 жыл бұрын
Thank you for watching
@Furki4_4 Жыл бұрын
The first example helped me to understand the pattern and second one showed me the wrong and silly way :D I tried to build different type of houses using builder design pattern to practise. I think I got it, thank you a lot !
@tracetv81153 жыл бұрын
Asp uses the builder pattern to isolate the complexity and make it easy to create an webhost for developers. Nice video!
@RawCoding3 жыл бұрын
Thank you for sharing
@androidsavior8 ай бұрын
I do not understand why the 'better' version is better except that you've added & used interfaces
@spuriustadius50343 жыл бұрын
Thanks for the clarity, again, Raw Coding! We always have a choice for how we construct objects (and collections of objects). How do you decide between using the Builder pattern vs the Factory pattern vs straight-up new()'s? The builder, it seems, allows for the possibility of run-time construction in a flexible way that can vary based on input/events. I also use it because I am making a lot of changes when I am trying to develop something and that flexibility is useful. In my case, I have to build a collection of objects in a many-to-many relationship with complicated constraints. For this, I've been using "faceted builders". But when object creation stuff stops changing, a "one-step" creation process becomes attractive. I have ended up putting builders "inside" factory classes when I need one-step creation. I am not sure if that's a "code smell" or not. It seems to work. Are there gotchas?
@RawCoding3 жыл бұрын
Yea I find "faceted builders" useless unless they are more than proxy methods as I explained in the video. (For example StringBuilder always creates a string representation however it's an optimized way to dynamically construct a string) The builder pattern is re-usable construction process with replaceable representations. We swap the builder and create different representations of the same data. The factory pattern is centralised and replaceable construction process of an object. We swap the factory (or change the factory method) and get a different instance. > How do you decide between using the Builder pattern vs the Factory pattern vs straight-up new()'s? Depends on the use case and you have to be able to see the pattern emerge from your code. Specifically you can decide if a pattern in applicable is - if you can prove with an example of how you are going to substitute it in the future, how often you'll need to substitute it and what will cause the substitution that will make the design pattern application valuable. Design Patterns are an investment.
@deepverticlive83754 ай бұрын
Wow, that comment at 06:00 hit me personally xD
@haribalachander3 жыл бұрын
Anyone else feels that Audio volume goes low and back up again in certain sections of the video ?
@RawCoding3 жыл бұрын
It does, thank you for telling me
@sorinvasiliu2 жыл бұрын
Awesome video, succint, on point, digestable. Excellent. Ty!
@RawCoding2 жыл бұрын
thank you for watching
@RichardONeil3 жыл бұрын
Really enjoying the videos. Thanks for creating them. When using this pattern, are we creating a side-effect on the object? I know that's a c#-OOP kind of thing, but everybody seems to be obsessed with avoiding them. Is there anything to that?
@RawCoding3 жыл бұрын
The side effects are contained within the builder instance. The kind side effects you want to avoid are the ones that leak outside of the expected scope.
@sorinvasiliu2 жыл бұрын
Awesome!
@RawCoding2 жыл бұрын
Glad you liked it
@pantelisioannidis25492 жыл бұрын
Some times people use Builder pattern to design a fluent api. In that case even the second internet example is ok.
@WayneGreen-g8l Жыл бұрын
The beginning example and end example seem to me to do things the opposite way. The beginning example has various builders that can go into one ConstructionProcess. The end example has one builder (CarBuilder) that can go into various construction processes: BuildRedLada, or conceivably into a BuildPorsche, BuildFerrari, etc.
@prayashff8803 жыл бұрын
well explained! loved it
@RawCoding3 жыл бұрын
Cheers
@TheTheokatz3 жыл бұрын
Hi! Very straightforward and interesting video, it really helped me to see the wrong application of this pattern. But I have one question, in the correct use of the builder pattern in the car example it's mandatory that the fields of car can be set publicly since the builders need to access those properties to assign their values. What if I nees these fields to be private? Is there any way to apply this pattern in that case?
@RawCoding3 жыл бұрын
Sounds like you are doing something wrong, how would you construct that object if you didn’t have a builder?
@TheTheokatz3 жыл бұрын
@@RawCoding Without using the builder pattern I would instantiate with a public constructor. I've found a way of solving my problem, declaring the builder nested inside the class that it's meant to build, this way it has access to the base class private fields.
@muddyPassenger3 жыл бұрын
Great, comrade!
@RawCoding3 жыл бұрын
Да
@getright202 жыл бұрын
Thank you for the video. Is it possible to create few more examples about this pattern?
@RawCoding2 жыл бұрын
Don’t think I’ll be making more examples for this
@chefbennyj3 жыл бұрын
Now I realize I have made these mistakes. I have work to do. When you switch to the ICarBuilder, is that the substitution principal in solid?
@RawCoding3 жыл бұрын
Not quite, LSP cares about the implementation details in the hierarchy so children are backwards compatible.
@abcdeika3 жыл бұрын
Great video, Anton! Thank you for those. Although I disagree with you that the initial CarBuilder was "bad". Well, if it's one kind of a builder, then what's the need for the interface? It's when another builder comes up we should define an abstraction, don't you think? Well, that, or if builder is needed in kernel-independent-module then an interface is declared. What's your position on immutability in OOP? I've watched your video today, and although it shows how to work with mutable objects and come up with a builder, it didnt help me to understand how to work with immutable object. Of course, if an object is mutable, then this kind of builders are redundant. That's why you suggest add some logic or validation - it makes sense. But for immutable objects this kind of builders should be enough, what do you think? Also, if I use an "IBuilder" abstraction in my constructor, how do I build the object then? It's gonna keep building the object but never finishing it - in your abstraction there's no "Build" method. Wouldn't it be good to define an interface "IBuilder" with any appropriate set methods AND "TModel Build();" method? Or something like this. Thank you for your attention. Your vids are great and I hope someday to be posting this kind of content myself. It's great to share knowledge between fellow developers!
@RawCoding3 жыл бұрын
> Well, if it's one kind of a builder, then what's the need for the interface? It's when another builder comes up we should define an abstraction, don't you think? the interface is there in anticipation of the change, adding that after the fact means isn't bad it's just un planned. It's like wearing the seatbelt before you crash, rather than starting to put it on after you've already crashed once. > What's your position on immutability in OOP? I've watched your video today, and although it shows how to work with mutable objects and come up with a builder, it didnt help me to understand how to work with immutable object. mutability is fine and use it where you need it, probably doesn't make much sense to use it in a builder but if you would I'd probably go for a new builder after adding each new property so you'd have the same effect as if you'd be using IEnumerable generators. > Of course, if an object is mutable, then this kind of builders are redundant. That's why you suggest add some logic or validation - it makes sense. Not necessarily, but I think you understand that the builder needs to do more that just be a proxy for the setting the properties, not just validation. > But for immutable objects this kind of builders should be enough, what do you think? I think the builder would look very different for immutable objects. > Also, if I use an "IBuilder" abstraction in my constructor, how do I build the object then? It's gonna keep building the object but never finishing it - in your abstraction there's no "Build" method. the point is that we don't know how to complete the build, we just know what we want - 4 wheels , 2 doors, engine, steering wheel - and when you build it you'll build a Ford or Volvo, Toy, Sculpture, Painting, Idea, Transaction Record etc... > Wouldn't it be good to define an interface "IBuilder" with any appropriate set methods AND "TModel Build();" method? Or something like this. that's hard coupling to the thing you are building, again we don't necessarily want to depend on what we are building when we are building it > Thank you for your attention. Your vids are great and I hope someday to be posting this kind of content myself. It's great to share knowledge between fellow developers! No worries, thanks for watching my video and hope this helps. And remember no better time to start than now )
@abcdeika3 жыл бұрын
@@RawCoding alright I got your point. Yeah, I see at clearer now. I'm just looking at the pattern a bit differently. Call it creative vision haha! Lets see where it takes me :) I'm looking at Builder as a specific builder to handle complex objects creation. For example, since I'm striving for immutability, I have 20 properties and I can't set them all in constructor: that's overkill + I want flexibility in providing those values. One way to solve this problem would be to use all arguments as optional, but I could really use builder-methods-validation and encapsulation for some properties. In short, there are trade-offs. Also in my domain there's no need for different build() although, now as I'm writing this, I can see that I might be having Build() for different models-mapping. And the inner properties-values might be stored in a dictionary. Huh! I've got to do some experimenting. Bah, I think I'm really onto your side of view of Builder pattern, so I ain't gonna bother you no more xD Anyway, I've understood your point and appreciate your opinion. Makes me look at this from a different angle. That is cool. Can we expect some videos about immutability? I thought it might be an interesting topic since you've dived in functional languages (Clojure, right?)
@inkofthedragon Жыл бұрын
Do you think the Builder Pattern could be an effective way to build different kinds of AiControllers with different behaviours/states and abilities, say for an Orc, Goblin, Troll, etc? Would the architecture flow look like? Thanks
@ivanvincent75343 жыл бұрын
Does a build method infer usage of the builder design pattern under the hood in the .net framework?
@RawCoding3 жыл бұрын
Yes
@lilbrothaizwatching2 жыл бұрын
So much information - and i google: lada.
@rajenlenka78063 жыл бұрын
Thank you Sensei
@RawCoding3 жыл бұрын
Thank you for watching
@MetaArcher3 жыл бұрын
thank youu for this. This videos are a really great introduction. Quick question, if for some reason the builder receives invalid parameters ( maybe a wrong color), how should he handle it? An exception?
@RawCoding3 жыл бұрын
I personally do not like exceptions, but you can use them. You can also make the result of the add/set function return the result of the operation. You can have a validate function before building.
@mahmudx2 жыл бұрын
you are the best.
@codeinsights82303 жыл бұрын
Your videos are very helpful. Can you make a video where you would describe and explain Visitor pattern? Thanks
@RawCoding3 жыл бұрын
That’s in the pipeline
@erhanalankus3 жыл бұрын
Thanks!
@RawCoding3 жыл бұрын
No thank you!
@pedroferreira92343 жыл бұрын
Amazing job! Its possible to show some of this patterns in "real projects"? 🙌
@chetankharel44353 жыл бұрын
Fluent validation and fluent migrations are some packages built with builder pattern
@pedroferreira92343 жыл бұрын
@@chetankharel4435 and stringbuilder if im not mistaken
@RawCoding3 жыл бұрын
StringBuilder is slightly different because it contains a mutable string that is very efficient at changing. You’ll always get a string at the end, so it’s not quite what I am explaining but it’s still a valid use of the builder because it’s not just proxy methods
@la-pantarana3 жыл бұрын
Anyone else find the joke at 5:41 funny? I keep replaying it XD
@RawCoding3 жыл бұрын
))
@jeong-ahyoon90776 ай бұрын
You are so good
@hassankuraimi88763 жыл бұрын
Could you Share the Books titles you spent you weekend on please
@RawCoding3 жыл бұрын
Worst outro decision ever. You can find the list of books in the comments of the factory video.
@hassankuraimi88763 жыл бұрын
@@RawCoding I got the book (Pro Memory Management) but then i though who ever cares about memory nether customer nor companies but i want to ask you if you have some kind of books that really made an effect could you help me with that ? and i'd like to say thank you so much i love your content its easy and attractive just keep going sir hope you the best
@RawCoding3 жыл бұрын
I recommend Uncle Bobs books and learn Clojure. And you should care about Memory.
@DagothThorus11 ай бұрын
5:10 I'm dying
@alvinbernardo9551 Жыл бұрын
your awesome, can have a video in linq, as in on depth
@vishalpandey41763 жыл бұрын
Nice explanation 👍🏻
@RawCoding3 жыл бұрын
Cheers
@ЕгорБрызгалов-й7ж3 жыл бұрын
Спасибо!)
@RawCoding3 жыл бұрын
Спасибо тебе )
@nikosevangelopoulos36053 жыл бұрын
where can i apply for your company? lol
@RawCoding3 жыл бұрын
Don’t have one yet :P
@nikosevangelopoulos36053 жыл бұрын
Not Yet! Good job man, very nice explanations in the videos and nice touches of humor