Builder Design Pattern (C#)
HTML-код
- Опубликовано: 16 сен 2024
- Explanation & examples for how to use the Builder design patter and how not to use it.
Patreon 🤝 / raw_coding
Courses 📚 learning.raw-c...
Shop 🛒 shop.raw-codin...
Discord 💬 / discord
Twitter 📣 / anton_t0shik
Twitch 🎥 / raw_coding
👉 Try Rider
www.jetbrains....
RD5K9-4TXXW-KMV3G-NYWSF-3ZSTP
Playlist: • c# design patterns
Source: github.com/raw...
#csharp #designpattern #builder
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 :/
Great example!
Для изучения языка решил послушать про известные мне паттерны на английском. И на тебе - красная Лада!))
🚗...
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!
thank you for the kind words
Asp uses the builder pattern to isolate the complexity and make it easy to create an webhost for developers.
Nice video!
Thank you for sharing
Finally All this happening as said earlier that will do this in future, time has come. Thank you Anton sir
Thank you for watching
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 !
Wow, that comment at 06:00 hit me personally xD
Awesome!
Glad you liked it
Awesome video, succint, on point, digestable. Excellent. Ty!
thank you for watching
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?
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.
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?
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.
Great, comrade!
Да
Anyone else feels that Audio volume goes low and back up again in certain sections of the video ?
It does, thank you for telling me
well explained! loved it
Cheers
I do not understand why the 'better' version is better except that you've added & used interfaces
Some times people use Builder pattern to design a fluent api. In that case even the second internet example is ok.
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.
5:10 I'm dying
you are the best.
You are so good
Thank you for the video. Is it possible to create few more examples about this pattern?
Don’t think I’ll be making more examples for this
Anyone else find the joke at 5:41 funny? I keep replaying it XD
))
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!
> 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 )
@@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?)
your awesome, can have a video in linq, as in on depth
Your videos are very helpful. Can you make a video where you would describe and explain Visitor pattern? Thanks
That’s in the pipeline
Amazing job! Its possible to show some of this patterns in "real projects"? 🙌
Fluent validation and fluent migrations are some packages built with builder pattern
@@chetankharel4435 and stringbuilder if im not mistaken
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
So much information - and i google: lada.
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?
Sounds like you are doing something wrong, how would you construct that object if you didn’t have a builder?
@@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.
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?
Not quite, LSP cares about the implementation details in the hierarchy so children are backwards compatible.
Thank you Sensei
Thank you for watching
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
Thanks!
No thank you!
Could you Share the Books titles you spent you weekend on please
Worst outro decision ever.
You can find the list of books in the comments of the factory video.
@@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
I recommend Uncle Bobs books and learn Clojure. And you should care about Memory.
Does a build method infer usage of the builder design pattern under the hood in the .net framework?
Yes
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?
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.
Nice explanation 👍🏻
Cheers
Спасибо!)
Спасибо тебе )
where can i apply for your company? lol
Don’t have one yet :P
Not Yet! Good job man, very nice explanations in the videos and nice touches of humor
Cheers :D
Are you from Russia?
Да
Why that fucking lada?)
Cuz it’s bad boi mobele
@@RawCoding thanks for videos)
🤍