Great video!! It may help that we reuse the variable "pizza" and keep re-assigning it to each decorator instance. It makes it clearer that "one thing" is being transformed through decorations. IPizza pizza = new Pizza(); pizza = new CheeseDecorator(pizza); pizza = new TomatoDecorator(pizza); pizza = new OnionDecorator(pizza); ....
the video was very good, it dealt with in a simple way, I missed UnitTest and how to do the injection depedency could you include these steps in the next videos? example using FluentAssertion.
Can I also re use the variable "pizza" instead of creating new variables with differenet names and passing them? So that I can only have one instance of pizza being upgraded until It got passed through all decorators?
No, he needs to called then for what they are, toppings. That way the references in the code are clearer and understandable. He can use "toppings" for all three and leave pizza as pizza which is what it is.
Instead of calling each decorator reference by specific name, like onion decorator, cheese decorator, etc call them all "toppings" and that way you can interchange the order without having to change the references in their constructors.
What if I want to bundle that functionality into an Attribute so it's as simple as applying an Attribute to a Method and getting the functionality added?
OOP is unnecessarily complicated. I haven't seen any real world implementation of most of these "patterns". Most devs either don't have time or expertise or even interest/enthusiasm to go around playing with objects. People just write code for work. OOP creates more problems than it promises to solve by creating more technical jargon. Composition > Inheritance. That's why JS wins.
I looked at several explanations before watching this. Yours finally made it simple and easy to understand. Thank you.
Great video!!
It may help that we reuse the variable "pizza" and keep re-assigning it to each decorator instance. It makes it clearer that "one thing" is being transformed through decorations.
IPizza pizza = new Pizza();
pizza = new CheeseDecorator(pizza);
pizza = new TomatoDecorator(pizza);
pizza = new OnionDecorator(pizza);
....
Good suggestion, thanks
It's very simple explanation, but also it's so useful, thanks for explanation!
Amazing video, would love to see more, though I suggest that you add a UML diagram in the future.
Finally Eminem explained it very well. Thanks alot.
This video gave the clear picture. Referring many sites didnt help me. Thanks a lot... Could you also provide videos on designing any architecture
Man, you nailed it. If you can made me understand this, you're good at explanation! lol
the video was very good, it dealt with in a simple way, I missed UnitTest and how to do the injection depedency
could you include these steps in the next videos?
example using FluentAssertion.
Great video, I prefer the builder pattern
Thanks for making this easier to understand!
Great Job. Thank you for this Charitable Endeavour.
thank you so much for this simple explanation.
nice and clean code, clear explanation. thanks.
The simplicity is great for comprehension, but one question I still have is how to handle other methods not explicitly extended by the decorator.
Great and very clean video, thank you!
Thanks 👍
That's pretty good. Thanks for the explanation.
Best explanation ! I've never had before Thanks so much
You're very welcome!
Can I also re use the variable "pizza" instead of creating new variables with differenet names and passing them? So that I can only have one instance of pizza being upgraded until It got passed through all decorators?
I think the same: adding decorators to pizza. At the end, call a pizza type, then show all itens added.
No, he needs to called then for what they are, toppings. That way the references in the code are clearer and understandable. He can use "toppings" for all three and leave pizza as pizza which is what it is.
Quick and well explained, thanks!
Thanks for this video!
wow...what a nice pizza..!! I mean nice tutorial 😂. Keep it up ❤️
It was really simple.. Thank you
Glad it helped!
This was an amazing example, Thank you so much man!!!!
nice and simple :p
Wow, really clarified it to me, thanks!
Instead of calling each decorator reference by specific name, like onion decorator, cheese decorator, etc call them all "toppings" and that way you can interchange the order without having to change the references in their constructors.
This looks like inheritance. What if you want to "decorate" existing methods that you can't change?
Thanks
What if I want to bundle that functionality into an Attribute so it's as simple as applying an Attribute to a Method and getting the functionality added?
Nice idea. Will have look into that.
@@CodeRadiance I look forward to seeing your results. 😉
@@CodeRadiance if you implemented with Attribute, plz share that video link
Great thanks
Thank you!
Good man.
lol i got a bit confused for a moment when you started talking about pizza. i thought it was some programming term i had never heard of
Lol
Damn it, now I am craving for pizza
❤️🍕🧑💻
Lit!
Who puts the cheese on the bottom? :D
I do. ;}
Bro made head first design patterns book a video. Just get the book everyone
your first example spells decorator wrong
OOP is unnecessarily complicated. I haven't seen any real world implementation of most of these "patterns". Most devs either don't have time or expertise or even interest/enthusiasm to go around playing with objects. People just write code for work. OOP creates more problems than it promises to solve by creating more technical jargon.
Composition > Inheritance. That's why JS wins.
Yeah js makes composition extremely easy to implement.