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.
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.
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.
@@georgeyoung2684 That's mapping an interface to an enum, but yes, adding something like getDiscriminator and returning the corresponding enum is enough.
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.
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
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.
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
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 ?
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
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.
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 work! awesome examples! Would you mind if I borrow your presentation style and examples for my blog post? I’m covering this topic as well, and I’ll include a link to this video as a reference. Thank you!
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 !
The extra indirection can be made easier on the reader by hiding details (i.e. is it multi channel, x channel, y channel???). For example, if the multi channel notifier would have been named just Notifier (in a generic sense), we wouldn't have to care about it being multichannel or whatever, or whatever that means, it would just be a notifier, that uses purpose-build notifiers, like email notifier and sms notifier, but we don't care about that, because our notifier can handle all types of notifications so we can use it everywhere, even where previously an sms notifier was used, or an email notifier was used. By hiding implementation details, including the details of what design patterns are used in the code, we can make it easier for other to read the code and understand what's going on without doing too much digging (i.e. jumping through all the layers of indirection).
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?
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?
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)
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.
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?
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 👍
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.
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
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?
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!
This is exactly how it should be! Short and sweet! Straight to the point!
Just watched your simple breakdown of the Strategy Pattern and this one. You do have a skill for this. Keep posting, loving this. Subscribed.
Much appreciated!
This is such a great video, cleared all my confusion on how to match these two patterns in 4 minutes !
Glad it was helpful!
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
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.
Man this was satisfying. I just wish I'd be able to remember this stuff when I'm actually coding the service lmao
Glad you enjoyed it
Incredible explanation, I love the way you tie the string of several concepts
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.
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.
@@georgeyoung2684 That's mapping an interface to an enum, but yes, adding something like getDiscriminator and returning the corresponding enum is enough.
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.
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
Enjoying your videos and liked the presentation. Keep going
This’s a very helpful video. I really enjoy the knowledge and look forward to watching more of this types of video. 🎉
Glad you enjoyed it!
It finally clicked on my end. Thanks!
the editing is superb!
upload more design pattern videos like this. keep it up!
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.
Great content!!! Awesome! Could you make some extra videos for other design patterns explaining in the same way? Thanks again.
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
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 ?
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
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.
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 work! awesome examples! Would you mind if I borrow your presentation style and examples for my blog post? I’m covering this topic as well, and I’ll include a link to this video as a reference. Thank you!
Good job bro. Keep it up!
Thank you!
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 !
Was about write the same thing!
Love these videos and the animation. Can you make videos for other design patterns?
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
The extra indirection can be made easier on the reader by hiding details (i.e. is it multi channel, x channel, y channel???). For example, if the multi channel notifier would have been named just Notifier (in a generic sense), we wouldn't have to care about it being multichannel or whatever, or whatever that means, it would just be a notifier, that uses purpose-build notifiers, like email notifier and sms notifier, but we don't care about that, because our notifier can handle all types of notifications so we can use it everywhere, even where previously an sms notifier was used, or an email notifier was used. By hiding implementation details, including the details of what design patterns are used in the code, we can make it easier for other to read the code and understand what's going on without doing too much digging (i.e. jumping through all the layers of indirection).
This is how I see it:
When you are in a "selection" scenario: Use strategy.
When you are in a "choice" scenario: Use Factory
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?
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?
Does the class OrderNotificierFactory violates Open Close Principle since it needs to be modified every time when a new notification service is added?
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)
In this case Open Close Principle is probably just wrong.
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.
Damn, these vids are amazing!
Thank you! Appreciate the positive feedback
Great one, what about a combo between bridge and also Factory, i think it could be great as well this
I knew you would do this video!
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?
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 👍
Great example!
Great channel. Keep it up :)
this video is gold
Unrelated question, but what font you use for the code in the video? Looks very nice
I think it’s JetBrains Mono
smooth animation af
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.
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
More please
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.
Isn't this the same as polymorphism
man how do i think like this
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.
The only pattern is state management.
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
It’s C#, I believe
Yeah it’s C#. Using a feature called Primary Constructors