Simplify Configuration via Polymorphism

Подписаться 22 тыс.

Просмотров 1,9 тыс.

50% 1

Learn how to leverage polymorphism and various design patterns in order to simplify configurations in your application!
🕗 Timestamps:
0:00 - Introduction
0:18 - Problem
2:14 - Solution Part 1 (Decorator)
8:07 - Solution Part 2 (Builder)
13:02 - Summary
📦 Source code: github.com/SingletonSean/.net...
💎 Become a Member: / @singletonsean
🏠 Discord: / discord
🐤 Twitter: / singletonsean_
🏆 Donate: www.paypal.com/donate?hosted_...
✉️ Email: youtube@singletonsean.com
➖➖➖➖➖➖➖➖➖➖
© Credits
🎵 Outro: pixabay.com/music/synthwave-c...

Наука

Опубликовано:

20 июл 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 15

@rlyonsiii 5 месяцев назад

Great video Sean, yes you had me itching for you to convert this to the Fluent Builder Pattern :) Keep up the great work!

@SingletonSean 5 месяцев назад

Thanks! And yes, couldn't leave out the satisfaction of a fluent builder 😁

@user-ho2ru6qb7f 5 месяцев назад

The builder in itself violates the open-closed principle, does it not? To remedy this, you could add a CartItemBuilder With(Func) method. The factory method could be any decorator constructor with any number of additional parameters such as a variable discount. It is verbose, but you can still chain instead of composing. Another alternative could be CartItemBuilder With(params object[]), but it would have to rely on reflection.

@SingletonSean 5 месяцев назад

That's a cool idea! I might have to play around with that first solution you suggested. Although I do like how the client of the builder in this video doesn't have to know about any of the underlying types since the builder encapsulates everything. I think violating the open-closed principle is okay here. I feel like the builder pattern here prevents us from violating the open-closed principle all throughout our application. You raise a really interesting point though, and it has made me think deep about this hahah

@user-ho2ru6qb7f 5 месяцев назад

If the decoratee were a property instead of a constructor argument, you could add it to ICartItem and be able to use the new() type constraint and property to instantiate decorators without reflection. You still cannot use more parameters, but your builder could store the list of types and your Build method would iterate instead of branch.

@adam-xt8te 5 месяцев назад

Ctrl+Shift+A -> fast adding new file to the project. VS generate template basing on file extension

@GnomeEU 5 месяцев назад

One big disadvantage with the builder pattern I see is what if you want to find all items that have x and y. How do you search that in your codebase? Interfaces also mess with your project navigation. You destroy the F12 key once you start with interfaces. And you clutter your discount logic over 20 different implementation files.

@Imgone251 5 месяцев назад

In the example in the video, couldn't you just look for all instances where the specific builder methods were called? Also for interfaces, in Visual Studio you can use the shortcut Ctrl+F12 when highlighting the interface to list all implementations of it.

@WillEhrendreich 5 месяцев назад

I think the csharp missing discriminated unions really is pretty glaring here. In fsharp this would be a simpler solution that uses a D U and favors composition over inheritance more fluently and simply.

@masterycgi 5 месяцев назад

why no having a list of element of type configuration in the list, so you don't have to add a boolean for every configuration. you only would have to add configurations to the list and then build will apply each one with a loop over the list

@SingletonSean 5 месяцев назад

Good idea!