Master the Builder Pattern: The King of Creational Design Patterns in C# | ASP.NET Core Tutorial
Vložit
- čas přidán 14. 06. 2024
- The source code from this demo is available on Patreon: / master-builder-c-82873108
Ever wondered how to handle the complex rules that govern the creation of a large object in your C# code? This detailed tutorial on the Builder Pattern in C# is here to guide you! Unlock the power of design patterns in software engineering as we delve deep into a realistic ASP.NET Core application scenario.
We explore the encapsulation of complex object creation processes and learn to achieve immutable objects through fluent interfaces. Understand the differences between Builder and Factory patterns as we walk through examples of the Builder Pattern, including how to implement a Builder Interface.
In this tutorial, we also touch upon the nuances of parameterized constructors and the construction process in the context of object creation. By the end, you'll be well-equipped to unleash the Builder, the king of Creational Design Patterns!
⌚ 00:00 Introduction to the Builder pattern
⌚ 00:56 About the demo ASP.NET Core application
⌚ 04:14 Defining the customer's requirements
⌚ 05:47 Designing the Builder's public interface
⌚ 09:53 Implementing the entire Builder
⌚ 14:52 Demonstrating the Builder in action
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
⭐ Learn more from video courses:
Beginning Object-oriented Programming with C# ► codinghelmet.com/go/beginning...
⭐ Collections and Generics in C# ► codinghelmet.com/go/collectio...
⭐ Making Your C# Code More Object-oriented ► codinghelmet.com/go/making-yo...
✅🔔 Become a patron ► / zoranhorvat
✅🔔 Subscribe ► / @zoran-horvat
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
⚡️ Have a look at our other Videos :
👉 Using GitHub Copilot to Write Complex Code | Step-by-step Tutorial ► • Using GitHub Copilot t...
👉 Coding with GitHub Copilot - Beginner to Master | VS Code Demo ► • A Comprehensive Guide ...
👉 What is Covariance and Contravariance in C# ► • What is Covariance and...
How to Initialize a Clean ASP.NET Core Project with Entity Framework Core and Identity ► • How to Initialize a Cl...
👉 The Null Conundrum: A Guide to Optional Objects in C# ► • How to Avoid Null Refe...
#zoranhorvat
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
⭐ CONNECT WITH ME 📱👨
🌐Become a patron ► / zoranhorvat
🌐Buy me a Coffee ► ko-fi.com/zoranhorvat
🗳 Pluralsight Courses ► codinghelmet.com/go/pluralsight
📸 Udemy Courses ► codinghelmet.com/go/udemy
📸 Join me on Twitter ► / zoranh75
🌐 Read my Articles ► codinghelmet.com/articles
📸 Join me on LinkedIn ► / zoran-horvat
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
👨 About Me 👨
Hi, I’m Zoran, I have over 20 years of experience as a software developer, architect, team lead, and more. I have been programming in C# since its inception in the early 2000s. Since 2017 I have started publishing professional video courses at Pluralsight and Udemy and by this point, there are over 100 hours of the highest-quality videos you can watch on those platforms. On my CZcams channel, you can find shorter video forms focused on clarifying practical issues in coding, design, and architecture of .NET applications.❤️
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
⚡️RIGHT NOTICE:
The United States Copyright Laws recognize a “fair use” of copyrighted content. Section 107 of the U.S. Copyright Act states: “Notwithstanding the provisions of sections 106 and 106A, the fair use of a copyrighted work, including such use by reproduction in copies or phono records or by any other means specified by that section, for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research, is not an infringement of copyright." This video and our youtube channel, in general, may contain certain copyrighted works that were not specifically authorized to be used by the copyright holder(s), but which we believe in good faith are protected by federal law and the Fair use doctrine for one or more of the reasons noted above.
⭐For copyright or any inquiries, please contact us at zh@codinghelmet.com
#csharp #designpatterns #dotnet - Věda a technologie
It is amazing how, by using the right patterns and techniques, we can hide the complexity of the domain and show only the "intention revealing expression" (I loved this sentence) to the consumer. Thanks for sharing!
I have to say this pattern was one of the most complex for me to understand and I'm still struggling in knowing when and how to develop it in my own in the correct way. This a good example,complex though.. thanks for sharing
Great Lesson! I always learn something new with all your video sir. Thanks.
This is a good demonstration for me to understand Builder Pattern. Great lesson! Thank you for making that!
Keep up the good work. Very nice explanation with real world example.
Thank you Zoran for such good , real-world example
I'm glad you liked it!
Excellent video! And yes, this is a very complex example. It fits really great for scenarios like this one.
If I came up with a simpler example, then there would possibly be no justification to apply the Builder in the first place. I might also make a video that demonstrates how exactly it comes that we don't need a Builder in simpler cases.
I understand. I'd be more than happy to see another video with simpler alternatives, but take your time :). Thank you!
Great use case of builder with proxy methods, Before I just used it to create test data for complex objects , now I have some new insights😊
Excellent ❤
Excellent I would like to see how you do your strategy pattern and adapter pattern
I do have plans to demonstrate Strategies in one of the future videos.
Great Video! I would love if you produce some video about "Vertical Slices" vs "Onion/Clean Architecture" (vs whatever you find better 😁)
Oh I will! I will be speaking about vertical slices next week at the SDD London conference and I plan to add a short video with that part to CZcams when I get back.
Looking forward t see that :)
This is great content. Can we have the link to the full course showing how all the implemetations of the BOOK STORE app.
There is no full course at the moment. I might make it in the near future, though.
@@zoran-horvat will be on the lookout then... ☺️
Thank you for the great video! What if we need to guide the users of the builder on which method they can use next? For instance if builder has mandatory steps or one steps can be called only after others? I guess we can introduce different interfaces and return them after each operation. Maybe you can share what could be the better way of implementing such complex builder?
That is a good question, indeed! You may try this article I wrote a few years ago: codinghelmet.com/articles/advances-in-applying-the-builder-design-pattern
Not everything in that article would I back today, but it should be about the topic you have mentioned here.
Thank you so much!
Is it good practice to use business logic in builder method? While unit testing the calculations will it not become diffcult?
This is a very specific builder - it is part of the domain model and it naturally contains domain logic.
However, if more requirements came, asking for variation, then the Builder would probably have to receive appropriate strategies or something of that sort.
Hi Zoran, I've noticed that Pluralsight have marked some of your Tactical Design Patterns courses and your "Making Your C# 6 Code More Object-oriented" course as retired. Would you still recommend watching these courses to somebody who have not gone through these before?
I still recommend those courses until I publish a new version. The problem with older courses is in the use of obsolete syntax, but on the positive side the themes gave not changed, and the way we address the problems is still the same.
@@zoran-horvat Thanks, i will check these out :)
Can we create an automated unit test for this builder class?
Yes, of course. It would test all invariants and postconditions from the specification of requests. Since none of the requirements has any variation, there is nothing to inject into the Builder, which makes testing easier.
Seems the builder is capturing domain concepts that belong to the invoice. The invoice itself is anaemic. How about capturing rules in the model itself and then a printer decoration object knows how to produce the output. Thoughts?
There is no problem in having domain rules in the builder if the builder is named after the domain it is building. Its whole purpose is to relieve the domain model from complex construction logic.
It is true that the domain model has remained empty (not anemic yet) after the change, but that is only because this is the demo code. I didn't implement any behavior of the invoices other than their construction and UI. You can imagine further requirements being implemented right in the invoices, and then you would appreciate them not being inflated with the construction logic.
@zoran-horvat Isn't this just a "Fluent Interface" implementation and not actual Builder pattern?
It is actually a fluent builder, like StringBuilder, for example.
This is a great example for encapsulating the extremely complex logic to make life easier for a caller. I have a question for this solution though. How would you unit test this? For example, AppendFee, AppendInterest and GetInterest for are complex enough on their own to have unit tests for each of them separately. But since they're private, you can't reach them from the tests (unless you make them internal and make internals visible in test project or public, but that brings up some red flags in design, so I don't think it's a good approach). You can test the builder as a whole, but since you call AppendFee(AppendInterest(deliquency)) in Build method, it would not really be trivial to know why some test failed - is it the fee calculation that's wrong or interest calculation? Or maybe both? Or maybe neither? Thanks in advance.
I would focus testing on the attributes of the product.
Builder normally has more than one responsibility, if we assume that each component it manages is a separate responsibility. Each component naturally requires unit testing, and so I envision it would be useful to focus on one component per test and keep all the rest at bare minimum. Then assert the qualities, the consequences caused by that component in the product.
I think that adding variation to the builder for the sake of testing would be overengineering. The whole purpose of the builder is to be the single point where the rules of composition are defined, so leave it be that way, that is my opinion.
@@zoran-horvat So, if I understood correctly, in the example of AppendFee(AppendInterest(deliquency)), you'd construct an object via the builder in which the AppendInterest(deliquency) would not change the deliquency at all (or as little as possible), but in that object there's a significant change done by AppendFee method for the result of previous operation and test the result? And another test would be vice versa - interest would "change the result a lot", while fee would make minimal or no difference to the final result?
@@m5s10 You can skip any method that is not mandatory and use simplest possible arguments in those that must be called. Then carefully call the method you are interested in, and assert that the result of that call has caused the expected change in the product.
@@zoran-horvat understood, thank you
I've used the builder method a couple times in the past, but instead of returning "this" I would return an Interface with the appropriate "next" steps exposed.
That is the fluent builder design. It is useful in cases when an unrestricted use of the builder could cause confusion and errors.
@@zoran-horvat Thanks! Great video's by the way.
Are you spying on me? I just used this pattern today.
I can't disclose my sources :)