Just wanted to say, you’re really good at this. I am a .NET OG. Spent 19 years in the stack, but switched these last 4 years to the Node/TS/Next stack for MERN. Have to come back to .NET now and all of this is a reminder of just how design pattern heavy this stack is. Was going through your channel and you don’t have a lot of videos. I think you have a true talent for braking things down and making them simple. Subscribed to hopefully see more and more content.

@jonowilliams26

Ай бұрын

Thank you! I appreciate the positive feedback. Best of luck returning to .NET

@Dom-zy1qy

Ай бұрын

I miss OOP sometimes, moved to nextjs stack and most of my non next backend is functional nodejs code.

@0xEncore

Ай бұрын

Im just curious, why do you prefer oop over funtional. Imo you could easily abstract this example with a simple notifyOrderShipped(order){ foreach (NT nt in order.user.NotificationChannels){ switch nt NT.push -> sendPush() …. } }

Geez, I've watched loads of videos about these patterns, but none has ever left me as satisfied as this one! Thanks, Jono, you're a ledge!

Love the format of this video. Short and well explained with great examples. Thanks for that. Hoping to see more design patterns videos like this soon

Man this was satisfying. I just wish I'd be able to remember this stuff when I'm actually coding the service lmao

@jonowilliams26

Ай бұрын

Glad you enjoyed it

This is exactly how it should be! Short and sweet! Straight to the point!

Enjoying your videos and liked the presentation. Keep going

Brief, yet extensive. A great video that got me hooked because of it's engaging and clear delivery. Many thanks for sharing.... have liked and subscribed for more content.

the editing is superb!

It finally clicked on my end. Thanks!

upload more design pattern videos like this. keep it up!

I'd go for mapping the notifiers to an enum value, injecting them into a map through DI, then just looping through the preferences which in a reasonable scenario would just be an array of enums. That way you can remove the complexity of the factory and MultiChannelNotifier and reduces the layers of abstraction.

@georgeyoung2684

Ай бұрын

Probably don’t even need to map anything, just add the notification type enum to the interface & concrete classes, then inject IEnumerable, then filter that based on the notification type being present in the preferences.

@CottidaeSEA

Ай бұрын

@@georgeyoung2684 That's mapping an interface to an enum, but yes, adding something like getDiscriminator and returning the corresponding enum is enough.

Was going to say "oh this is likely a clickbaity title" but actually yeah, strategy is actually a good pattern. One that I don't really think about anymore, but one that I should probably think about more.

I knew you would do this video!

Great channel. Keep it up :)

Great content!!! Awesome! Could you make some extra videos for other design patterns explaining in the same way? Thanks again.

This’s a very helpful video. I really enjoy the knowledge and look forward to watching more of this types of video. 🎉

@jonowilliams26

Ай бұрын

Glad you enjoyed it!

this video is gold

Damn, these vids are amazing!

@jonowilliams26

2 ай бұрын

Thank you! Appreciate the positive feedback

Good job bro. Keep it up!

@jonowilliams26

Ай бұрын

Thank you!

Its really great combo of patterns. Personally, i sometimes prefer to go one step deeper into abstractions 😅 and hide factory call + created service call into the same interface (IOrderNotifier in your case). It makes business logic cleaner a bit, no need to know infrastructure things like "factories" behind

In the past when I’ve done something similar to this I would still inject the different strategies into the factory using dependency injection, so the DI container can still handle the scopes, rather than having the factory create the instances.

More please

smooth animation af

Love the visualizations! The question that remains for me is how to test this code when the factory creates the objects rather than having proper dependency injection set up?

Great content! Looking forward to more videos about design patterns! Quick question: Is there a specific reason why you chose to inject the factory into the service instead of marking it as abstract and the creation method as static?

Great one, what about a combo between bridge and also Factory, i think it could be great as well this

This MultiChannelNotifier is more of a Composite than it is a decorator. Decorator is about run time polymorphism. Though i admit it does take some kind of inner notifier Great video !

@togofar

Ай бұрын

Was about write the same thing!

First of all, top notch editing and explanation. I think, however, that in the context of your example, the best choice for a design pattern would be the Observer pattern. The shipOrder method can easily dispatch an OrderShipped event and a notifier can later subscribe to this event and send the necessary notifications.

@jonowilliams26

Ай бұрын

That’s a really good point. Because there are probably multiple other things you want to do when an order ships. So a publisher & subscriber approach would be a great fit

Love these videos and the animation. Can you make videos for other design patterns?

@jonowilliams26

2 ай бұрын

Thank you! I have a backlog of videos, so hopefully a new animation every week or two. But won’t all be about design patterns

Wouldn't these design patterns make it harder to debug the program on very large systems? I find myself debugging for days on Chromium. If so, is there a design pattern that hits that middle spot?

Great video but there just one thing I don’t understand. Why the OrderNotifierFactory is a class that you need to instantiate and pass around. I know with some DI containers it’s manageable but your factory don’t have internal state and don’t respond to an interface ? Could you just not use a static method for that ?

@jonowilliams26

2 ай бұрын

Thanks!, Glad you enjoyed it and good question. For this example, you could have definitely just made the factory a static method and that would be a perfect approach. No need to overcomplicate things with DI if not needed. In this example I left out the configuration of the Email, SMS and Push service for brevity and I didnt have enough screen space in the video haha. Usually there would be some configuration for client id and secret, so the factory would need to take in some IConfiguration or IOptions etc. Then it probably makes sense to have a class with the configuration or options being injected etc

instead of using the MultiChannelNotifier, what if we just returned IEnumerable from the Create method inside of the factory? and just yield return the different channels?

@jonowilliams26

Ай бұрын

You could definitely do that. The only downside to that approach would be the caller is now responsible to loop through each channel, whereas the multi channel notifier handles that for you. But like anything, there is multiple ways to approach the problem, so whatever works best for you 👍

Does the class OrderNotificierFactory violates Open Close Principle since it needs to be modified every time when a new notification service is added?

@shayvt

Ай бұрын

I would implement the factory with either reflection to load the notifier (there are some approaches for this - property of notifier type on each notifier or an attribute on each notifier) or if you use ioc container, you can get a collection of all notifiers to the factory, then filter the one you need (you need to add property of the type on the INotifier)

@gJonii

Ай бұрын

In this case Open Close Principle is probably just wrong.

@CottidaeSEA

Ай бұрын

If the data is stored or at the very least loaded in a way where it's just an array of enums, that can easily be mapped to notifiers. In that case you can just have a registry (hash map) of those which are injected, then just say "I want this one" in your loop and construct the dependency array to send to the one which has multiple. I'd even say it is preferable to just store an array of the selections, because it is just easier to work with in general. Either you have a map for all users where the key is the notifier and the value is a boolean for active/inactive. It's easier to work with and would allow not needing to update the factory without making the notifiers more complex. It's not really necessary though, like gJonii mentioned, but it's an alternative. If you have the design that I mentioned, the factory and multi channel notifier are kind of redundant because you can just loop through the preferences and process them in the OrderService. Because you can use DI to inject configurations to the notifiers and you can use DI to inject a map of the notifiers, there's nothing left for the factory to achieve.

Unrelated question, but what font you use for the code in the video? Looks very nice

@jonowilliams26

Ай бұрын

I think it’s JetBrains Mono

Could someone help me clarify the differences between Factory and Strategy, they seem pretty similar to me and I just can't wrap my head around which is which. it seems to me Factory refers more to the object creation and Strategy to the behaviour/implementation, but in the strategy you also need to create the object so it feels like it's always a combination of the two? I really liked this video btw my head exploded when you implemented the MultiChannelNotifier.

@christoffertoftpersson895

2 ай бұрын

Factories help abstract away the details of how different objects are instantiated - which in its purest form is just a way of adhering to Di(we should not depend on concrete classes) a CarFactory for example could have methods makeBMW and makeToyota. Instead of your app depending on the BMW and Toyota classes (which are prone to change during development). Instead your app knows of the Car interface and can interact with the returned objects through that interface, which removes the dependency on the concrete classes.. Hth

man how do i think like this

Isn't this the same as polymorphism

The only pattern is state management.

idk if i like this, just create a prop on the user that returns all his notifications maybe with some reflections so u dont have to add always if checks?

The MultiChannelNotifier is a composite, not a decorator.

Love the whole thing. But that last bit in the end where you manually check which modes are enabled instead of a loop - argh!!

There's a typo on the thumbnail.

Just use functions with identical method signatures. Hate this obsession with creating a service for everything

Is this from any language in particular? I have never seen the syntax class notifier(orderNotifier[] Notifiers) : iordernotifier Before

@Chemest_a

Ай бұрын

It’s C#, I believe

@jonowilliams26

Ай бұрын

Yeah it’s C#. Using a feature called Primary Constructors