Tbh the decorator pattern is hard to wrap your head around because of the fact that you are acting on a shell, not the object, and that the shell can recursively call itself an unknown amount of times. That's what makes it so hard. The object doesn't contain the notifiers, the notifiers contain each other and the object. That in and of itself is totally different in it's way of thinkng compared the usual way of thinking that we have in OOP, which is think human like, not computer like. The decorator pattern is so hard fo this reason, it totally omits the usual way of thinking that we have when programming conventional OOP. The decorator pattern is almost a mirror of recursive funtions in functional programming. I learned that this is logical only after doing a functional programming course. To be fair, there are many ways to avoid using the decorator. A shell within a shell within a shell isn't nice conceptually and contextually, and it WILL lead to some nasty code. Using composition is good, but at least know what you are doing. Look at the decorator pattern for a moment and see the following. You call functionality a, which calls b, and c, and so on. But why? Let's say we have that notifier. We want to notify. How do we achieve this? When we do it we go down the line executing everything like a composed function chain. That to me sounds a lot like a pipeline. A simple example of this is middleware. You could achieve a middleware like behaviour by using the decorator pattern. But in fact, you could just use function composition instead. It would be a function that would take another function, and an optional callback function. Ones the calls are done, you will have achieved your result. It's the EXACT SAME THING. You wouldn't have to worry about objects having objects and so on. The functions that you pass can generate closures if needed so they can reference their origin object and it's values. C# does this under the hood, but you could just make your own closure if you wanted to. Now call notify, and see that you still call the one primary object that you tasked with notification. It's job is just to contain a chain, a pipeline, of functions or objects. Back to the decorator pattern, it does just this very thing. But human terminology is just really confusing as what you are doing isn't decoration, it's pipeline composure. Hell I am a first year informatics student and when I spotted this during the lecture the teacher sat down with me for three hours straight just to discuss this fenomena. It's so much easier when you use the correct terms. It's not a notificationdecorator, it's a pipeline pease. During our little chat (me and teach) we called them fragments, or pipe peases. NotificationPipelineFragment is what we used. We composed the entire thing again, just changing names. And the code? It was self explanatory. Balance was back in the world of WTF OOP, and it actually made more sense to the students (including myself). So to summon it up, the decorator pattern is hard because it is misunderstood, and people use the wrong terminology when using it. I personally thing that the decorator pattern is falsely named. Pipeline pattern, wrapper pattern, or callback compositional pattern would be a better suited name if we would go for something a bit more self explanatory. A hickup in modern day design, just because they used the word wrong. Do note that that's just for simple cases like this one as far as I know. And yes, there are cases for why decoration would be a somewhat valid term, but you would still be wrapping and forming a shell, just to have basic callback functionality. Often but not, the decorator uses the state of the inner contained object, or has complex logical relations with the contained object. But it the end it's still, and will always be, a pipeline of objects.
Been learning these as I go, and man while it’s tough to understand immediately, it feels so satisfying to have a go at them and understand how you can use them on your own
The other tutorials always executed a code on the decorator before executing the wrapped code, I didn`t think that I can call the wrapped code before, just like you did, nice video man.
Your video style is very well executed, helped me wrap my head around this topic. Especially the code example, and how the method calls bubbled up to parent classes. Keep up the high quality! Subscribed ❤
At 3:26, BaseNotifierDecorator class should not instantiate nor contain databaseService attribute, as DatabaseService is already instanciated in Notifier class, right ? Also, DatabaseService should have been injected in Notifier class by an IoC container.
Hey, can anyone tell me why Notifier is also implementing another system in its send function? I believe Notifier has to at least have a send function since it is based on INotifier. But in our current structure, won't every single implementation send message by mail even if it's not required?
Great video! I was wondering if it would be possible to use the Composite pattern here? We can have that Whatsapp and Email notifications implement the Notifier interface and then have compositeApps which can include any platform (Whatsapp, email, facebook, etc). Thanks in advance!
Other than one being Creational and the other being Structural, what is the difference between the Decorator and Factory pattern? I know in Factory the subclasses of the component can create an object of the subclasses of the Decorator class, but they seem to be implemented in the same way.
The Decorator pattern enhances the behavior of an individual object dynamically by wrapping it with additional functionality, while the Factory pattern provides an interface for creating instances of different classes without specifying their concrete types directly. In summary, the Decorator pattern enhances the behavior of an object, while the Factory pattern abstracts the creation of objects.
Thank you for your video, it is helpful. But i miss one thing. The problem with inheritance you introduced was that we need to create multiply subclasses such WhatsappSmsNotifier, SmsFacebookNotifier, WhatsappFacebookNotifier and then you introduced approach with decorators. The thing I dont understand how decorators solve your example problem ? If user wants to receive notifications via SMS and Whatsapp we still need to create a SmsWhatsappDecorator, dont we ? Thank you for your response.
Glad it was helpful :) Nope. You wrap your objects with two decorators instead of one. Using the singular classes we can now generate the permutations we want, contrary to the issue mentioned at the beginning. Cheers! Hope this answers it.
Question: Is it not better to use the observer pattern in this situation instead? I mean, it is much easier to store an array of notify objects and on notifyMethod, iterate through the notify array calling notify.execute(), if you know what I mean;
Many problems can be solved with the help of multiple patterns! Feel free to try it out! The video is more about explaining the pattern rather than trying to solve a specific question :)
how to send notification only to whatsapp ? or only to fb? with this approach? since the whatsappDecorator needs an instance of a INotfier can you please explain me this?
There is nothing wrong! However, this way, your code is more reusable, more flexible in case many clients have to make use it, and most importantly the structure of the calls (base call first and then decorators) is guaranteed at compile time. Cheers!
Thank you! Bless you as well :) Well, then maybe WhatsApp should be your base notifier, as per the design, the decorator is added on top of a default behavior, and in our case it was a mail! Cheers!
@@geekific yep, kinda used these patterns at work, but I have a software engineering exam Thursday and this helps in reviewing. Thank you a super duper lot ☕
Bro gotta be tired from carrying so many students through softwaredesign courses. No but seriously thank you soo much for your comprehensive content
Tbh the decorator pattern is hard to wrap your head around because of the fact that you are acting on a shell, not the object, and that the shell can recursively call itself an unknown amount of times. That's what makes it so hard. The object doesn't contain the notifiers, the notifiers contain each other and the object. That in and of itself is totally different in it's way of thinkng compared the usual way of thinking that we have in OOP, which is think human like, not computer like. The decorator pattern is so hard fo this reason, it totally omits the usual way of thinking that we have when programming conventional OOP. The decorator pattern is almost a mirror of recursive funtions in functional programming. I learned that this is logical only after doing a functional programming course.
To be fair, there are many ways to avoid using the decorator. A shell within a shell within a shell isn't nice conceptually and contextually, and it WILL lead to some nasty code. Using composition is good, but at least know what you are doing. Look at the decorator pattern for a moment and see the following. You call functionality a, which calls b, and c, and so on. But why? Let's say we have that notifier. We want to notify. How do we achieve this? When we do it we go down the line executing everything like a composed function chain. That to me sounds a lot like a pipeline. A simple example of this is middleware. You could achieve a middleware like behaviour by using the decorator pattern. But in fact, you could just use function composition instead. It would be a function that would take another function, and an optional callback function. Ones the calls are done, you will have achieved your result. It's the EXACT SAME THING.
You wouldn't have to worry about objects having objects and so on. The functions that you pass can generate closures if needed so they can reference their origin object and it's values. C# does this under the hood, but you could just make your own closure if you wanted to. Now call notify, and see that you still call the one primary object that you tasked with notification. It's job is just to contain a chain, a pipeline, of functions or objects. Back to the decorator pattern, it does just this very thing. But human terminology is just really confusing as what you are doing isn't decoration, it's pipeline composure. Hell I am a first year informatics student and when I spotted this during the lecture the teacher sat down with me for three hours straight just to discuss this fenomena.
It's so much easier when you use the correct terms. It's not a notificationdecorator, it's a pipeline pease. During our little chat (me and teach) we called them fragments, or pipe peases. NotificationPipelineFragment is what we used. We composed the entire thing again, just changing names. And the code? It was self explanatory. Balance was back in the world of WTF OOP, and it actually made more sense to the students (including myself). So to summon it up, the decorator pattern is hard because it is misunderstood, and people use the wrong terminology when using it. I personally thing that the decorator pattern is falsely named. Pipeline pattern, wrapper pattern, or callback compositional pattern would be a better suited name if we would go for something a bit more self explanatory. A hickup in modern day design, just because they used the word wrong. Do note that that's just for simple cases like this one as far as I know.
And yes, there are cases for why decoration would be a somewhat valid term, but you would still be wrapping and forming a shell, just to have basic callback functionality. Often but not, the decorator uses the state of the inner contained object, or has complex logical relations with the contained object. But it the end it's still, and will always be, a pipeline of objects.
To add to that, try looking at it like the decorations are addons. Addon pattern would be a weard name, but you get the general idea.
This is the best "Design Pattern" playlist.
You are an amazing teacher.
I had to watch this twice to fully understand it. I would have neverrrrr gotten it just via my course material. Thank you so much :)
This is the go to channel when you need a refresh on some design pattern
Been learning these as I go, and man while it’s tough to understand immediately, it feels so satisfying to have a go at them and understand how you can use them on your own
Thanks a lot mate. Your code examples helped very much, but also the diagram and general explanation. Exactly what I needed. You are a good Teacher.
The other tutorials always executed a code on the decorator before executing the wrapped code, I didn`t think that I can call the wrapped code before, just like you did, nice video man.
Glad I could help!
WTF, the way you explain things is the best ever I've seen!
Glad I could help
Your video style is very well executed, helped me wrap my head around this topic. Especially the code example, and how the method calls bubbled up to parent classes. Keep up the high quality! Subscribed ❤
what is the need to create basenotifier, we can just send it directly to the next object
Why can’t the client can instantiate two notifier classes and notify the user instead of creating subclasses of combinations?
At 3:26, BaseNotifierDecorator class should not instantiate nor contain databaseService attribute, as DatabaseService is already instanciated in Notifier class, right ?
Also, DatabaseService should have been injected in Notifier class by an IoC container.
Hey, can anyone tell me why Notifier is also implementing another system in its send function? I believe Notifier has to at least have a send function since it is based on INotifier. But in our current structure, won't every single implementation send message by mail even if it's not required?
Thanks a bunch.. awesome explanation.
Glad it was helpful!
Thanks for nice explanation of Decorator Pattern, it is really helpful. 😀😀
Waao, what an explanation!🔥
Everything makes sense now thank u 🍬👌
Thanks so much for this very clear course !
But in this example i can't have e plain facebook notifier without the email notifier (the first Notifier concrete component), right?
Great video! I was wondering if it would be possible to use the Composite pattern here? We can have that Whatsapp and Email notifications implement the Notifier interface and then have compositeApps which can include any platform (Whatsapp, email, facebook, etc). Thanks in advance!
Thanks for such great help!
Amazing content
Amazing Explanation
Other than one being Creational and the other being Structural, what is the difference between the Decorator and Factory pattern? I know in Factory the subclasses of the component can create an object of the subclasses of the Decorator class, but they seem to be implemented in the same way.
The Decorator pattern enhances the behavior of an individual object dynamically by wrapping it with additional functionality, while the Factory pattern provides an interface for creating instances of different classes without specifying their concrete types directly. In summary, the Decorator pattern enhances the behavior of an object, while the Factory pattern abstracts the creation of objects.
awesome, i sat 3 hours in a lecture to understand this, lol
Thank you for your video, it is helpful. But i miss one thing. The problem with inheritance you introduced was that we need to create multiply subclasses such WhatsappSmsNotifier, SmsFacebookNotifier, WhatsappFacebookNotifier and then you introduced approach with decorators.
The thing I dont understand how decorators solve your example problem ? If user wants to receive notifications via SMS and Whatsapp we still need to create a SmsWhatsappDecorator, dont we ? Thank you for your response.
Glad it was helpful :) Nope. You wrap your objects with two decorators instead of one. Using the singular classes we can now generate the permutations we want, contrary to the issue mentioned at the beginning. Cheers! Hope this answers it.
Question: Is it not better to use the observer pattern in this situation instead?
I mean, it is much easier to store an array of notify objects and on notifyMethod, iterate through the notify array calling notify.execute(), if you know what I mean;
Many problems can be solved with the help of multiple patterns! Feel free to try it out! The video is more about explaining the pattern rather than trying to solve a specific question :)
Thanks too much for your playlist.
in the example y do u have to send the email alongwith whatsapp and Facebook , like what if i want to send only by whatsapp and facebook
This is acting as a base behavior or our notifier, it could be anything else, and you could easily modify it
Great Video Bro.
where can i find the slides ?
We may add them in the future to GitHub, for now only code is available.
how to send notification only to whatsapp ? or only to fb? with this approach? since the whatsappDecorator needs an instance of a INotfier can you please explain me this?
If that is your use-case, then the decorator isn't the way to go. Each pattern tries to solve a specific problem. Cheers!
@@geekific thanks for the explaination understood now.
Question: why can’t the client just initiate three objects and call send() three times? Whats wrong with this approach?
There is nothing wrong! However, this way, your code is more reusable, more flexible in case many clients have to make use it, and most importantly the structure of the calls (base call first and then decorators) is guaranteed at compile time. Cheers!
i have a question . What if i want to only send the message by what's up ? Otherwise thank you for your efforts . May god bless you
Thank you! Bless you as well :) Well, then maybe WhatsApp should be your base notifier, as per the design, the decorator is added on top of a default behavior, and in our case it was a mail! Cheers!
Sorry but why cant you make a list of INotifiers, and call by iteration, instead of creating this ceremonial boilerplate?
isn't this just a microkernel architecture pattern?
god bless your soul
funny enough, the decorator pattern and chain of responsibility pattern are very similar, though the purpose is different.
Hope our videos are helping you understanding the purpose of each!
@@geekific yep, kinda used these patterns at work, but I have a software engineering exam Thursday and this helps in reviewing.
Thank you a super duper lot ☕
if someone only wants to send notification through slack, this code end up sending notification email also
Then it is not for your use-case!
As someone new to this I just had a bunch of words piled on words.
Can you please tell us which parts were the most confusing so we can try to help and improve in future videos?