i've banged my head against a wall for this concept or at least trying to grasp its practicality for a long time. the scales have fallen from eyes (via java😊). thanks!
If the Decorator Pattern is extending functionality via composition rather than subclassing, shouldn't we have interfaces rather than abstract classes?
the idea is to program to an interface, at some point in the development you will have to extend some classes. At the end of the day you're still using implementing an interface through an abstract class
A very good example, thank you. I have additional questions. With the class CoffeeDecoration, we add all additional which will have our let's say final object Espresso right? But if we want to add i.g. Machiatto will again implement Coffee and if Machiatto has something special we will that add in the same way as we added WithMilk, WithSugar, etc. Right? p.s. How did you generate the diagram with IntelliJ? I use the community version. If the community doesn't have can you please suggest some add to me and to others?
Thanks for the great explanation. I turned you code as an exercise to c# and it did not work. Only after i did this it worked. I had to create a CoffeeDecorator object on line 3 and a separate print method on line 5 :-) 1. Coffee espresso = new Espresso(); 2. printCoffee(espresso); 3. CoffeeDecorator espressoDecorator = new WithMilk(espresso); 4. printCoffee2(espressoDecorator); 5. private static void printCoffeeDecorator(CoffeeDecorator c) { Console.WriteLine("Cost: " + c.cost() + ", Description: " + c.getDescription()); }
Just wanted to let the viewers know that there is the 2nd edition of this book that’s out, while 1st Ed Is reviewed in the video, there are minimal differences.
Just wanted to say thank you. Nice and clear presentation. One question if you don't mind: Lets say I want to split business model class from ORM - would decorator pattern be the way to go? Simple example: there is a User class with id/email. One set of decorators would be ORM related, like table name, relationships, foreign keys, etc. Second set of decorators might be for example JSON response serialization. Does this make sense? Thank you in advance
What is the point of even having a Coffee Decorator class? Couldn't the WithMilk and WithSugar classes just extend Beverage and still work within the decorator pattern?
@@BeABetterDev Thank you so much! Now I've learned a new English word. Ignorant means something that Americans are allowed to do towards Russians but Russians aren't allowed towards Americans.
Hi! Thank you for your videos. I have a question. Isn't that correct that in the case of "espresso = WithSugar(espresso)", actually the espresso variable isn't Espresso, it's just Coffee? I mean, by using this pattern we lose properties and methods of Espresso class when we want to make it with sugar as opposed to the approach you told about at the beginning of the video
In this example what he is doing is creating the Abstract Base Class (ABC) "Coffee" which is the only thing known to the client code! This means that the client/code should deal with implementation specific methods/properties of the ABC class Coffee (the Interface). So the client should not aware of any specific methods or properties assigned to any concrete classes of Coffee (e.g. Espresso). If you start relying on specific methods of concrete classes then you are coupling code which needs to be altered if the implementation changes for those methods, and hence is violating the Open/Closed principle. What you instead could do is having "private" methods inside Espresso which are called once public method(s) of the Coffee Interface is called (getDescription(...) or cost (...) in this example) If this is not what you are looking for, then another design pattern could instead be appropriate, for example, Adapter Pattern or regular inheritance.
So to summarize, when creating a Coffee: Coffee espresso = new Espresso() or Coffee java = new Java() The code should only know that it is dealing with a Coffee, so you know that for each coffee instance you are able to call getDescription () and cost (). If you need to check the instance of the coffee whether it is an Espresso or Java, for example, to call specific methods/properties like getEspressoIngredients() (made up method). Then you are coupling your code to the concrete class Espresso, but what happenes if Espresso is taken off the menu? Then you need to change your code everywhere you are calling getEspressoIngredients(); which is violating open/closed principle and should be avoidable 😊
@@SuperSlugger94 No no, that's not what I meant. I know that Coffee is an abstract class and how we can use it. My point was that the expression "espresso = WithSugar(espresso)" is not useful because after the assignment we lose the specific parameters of the Espresso class. Let's say, as you said, Espresso has its own method getEspressoIngredients, ok, and let's say I want to use the ingredients somehow and send the cup to a client. What do I do? - I create the Espresso - Put the sugar into it - Get Espresso Ingredients - Finally, send the cup to a client Using the pattern I can't get Espresso Ingredients just because I put the sugar into it. That's the point. For some reason, putting the sugar into espresso doesn't allow me to use it as espresso without casting any longer. However, if I used the classic way that he mentioned at the beginning of the video with a method Add() I would be able to. Speaking of the coupling to specific methods, we could use a function sendCoffee() which accepts Coffee, not Espresso, not breaking anything.
@@22222222222222223464 Yes, now I see what you mean! It is exactly as you say! If you need the concrete classes of Coffee to be very unique in the sense that they provide completely different behaviors, for example getEspressoIngredients() and getJavaBeanSize(), then as you say this pattern isn't really useful! When decorating a concrete class it again becomes of the thing you are decorating + additional behaviors (but only in the sense of the ABC Interface), the ABC Interface is the only thing you know that won't change when you are decorating something! All other methods specific to concrete classes (e.g Espresso and Java) will disapear once it is decorated with e.g addSugar(Espresso), so it won't be reachable unless explicitly casting. So I see your point; in the scenario you are describing this pattern loses its purpose. However, if you only want to extend behaviors related to the ABC Interface then this pattern could be useful depending on your usecase.
Thank you. I finally understand what "Decorator" does.
Glad I could help!
I think you explained it better than the book did, actually.
I don't think there can be a better compliment than this :)
Yup. I subscribed
i've banged my head against a wall for this concept or at least trying to grasp its practicality for a long time. the scales have fallen from eyes (via java😊). thanks!
Thank you. I was lost when I get into the code of getDescription() in Head First. And also your suggestions are awesome.
this gonna save me from this semester😍 very clear and informative, BIG THANKS🥂
You're very wecome Marckhycs!
watched the first video and turned on the bell icon!
Thanks Himanshu and welcome!
Thank you! Working on a project for school and this helped a lot
Thankyou sir. I wish everybody would take the time to explain patterns like you.
lovely short and sweet explaination brother
Great voice! Good teaching!
you are the enlighter.....
I try my best :)
Thank you so much for the video. Very informative.
Glad it was helpful!
Really a good explanation. Thanks
Thanks Ramakrishna, you're very welcome!
Really good explanation!!
Thanks khomo!
If the Decorator Pattern is extending functionality via composition rather than subclassing, shouldn't we have interfaces rather than abstract classes?
Very clear, thank you 👌
Glad it was helpful!
really appreciate you doing these videos!
You're very welcome Rob!
good explanation buddy, that helps
You're very welcome!
Very good content. Congrats!!!!
Thank you so much 😀
Thank you!
It's a recursive strategy - one class decorator has a reference to another class decorator.
Well done!
But isn't it supposed to be an interface if you're implementing it. An abstract class if you're extending it.
the idea is to program to an interface, at some point in the development you will have to extend some classes. At the end of the day you're still using implementing an interface through an abstract class
Nice video, thanks
You're very welcome Joaquin!
A very good example, thank you.
I have additional questions. With the class CoffeeDecoration, we add all additional which will have our let's say final object Espresso right? But if we want to add i.g. Machiatto will again implement Coffee and if Machiatto has something special we will that add in the same way as we added WithMilk, WithSugar, etc. Right?
p.s. How did you generate the diagram with IntelliJ? I use the community version. If the community doesn't have can you please suggest some add to me and to others?
Thank you
Thanks a lot!
Thanks for the great explanation. I turned you code as an exercise to c# and it did not work. Only after i did this it worked. I had to create a CoffeeDecorator object on line 3 and a separate print method on line 5 :-)
1. Coffee espresso = new Espresso();
2. printCoffee(espresso);
3. CoffeeDecorator espressoDecorator = new WithMilk(espresso);
4. printCoffee2(espressoDecorator);
5. private static void printCoffeeDecorator(CoffeeDecorator c)
{
Console.WriteLine("Cost: " + c.cost() + ", Description: " + c.getDescription());
}
shouldn't espresso extends coffee? since coffee is an abstract class and not an interface?
Just wanted to let the viewers know that there is the 2nd edition of this book that’s out, while 1st Ed Is reviewed in the video, there are minimal differences.
Thanks for pointing this out George!
How can add mutilple functionlities dynamically? Like expresso withsugar and withMilk both..
learned a lot, thanks!
Great to hear, thanks Yasahan!
Just wanted to say thank you. Nice and clear presentation.
One question if you don't mind: Lets say I want to split business model class from ORM - would decorator pattern be the way to go? Simple example: there is a User class with id/email. One set of decorators would be ORM related, like table name, relationships, foreign keys, etc. Second set of decorators might be for example JSON response serialization. Does this make sense?
Thank you in advance
What is the point of even having a Coffee Decorator class? Couldn't the WithMilk and WithSugar classes just extend Beverage and still work within the decorator pattern?
great
thanks
You're very welcome! Thanks for watching Maksym.
Bien hecho, amigo (well done in your weird language of Inglish).
15:53 Huh? Surely most of that belongs in the superclass?
Can anyone tell me what's the name of his IDE?
IntelliJ Idea
Sorry to mention. Thanks for explaining nicely
@@BeABetterDev Thanks
I should not buy the book. it says to much. i prefer your way of teaching :P
Still don't see how this is a useful pattern. It doesn't prevent infinite classes.
coffee shop, pizza shop, cooking pizza, making coffee...
do Americans do something except for devouring?
That is a very ignorant thing to say.
@@BeABetterDev Thank you so much! Now I've learned a new English word. Ignorant means something that Americans are allowed to do towards Russians but Russians aren't allowed towards Americans.
Hi! Thank you for your videos. I have a question. Isn't that correct that in the case of "espresso = WithSugar(espresso)", actually the espresso variable isn't Espresso, it's just Coffee? I mean, by using this pattern we lose properties and methods of Espresso class when we want to make it with sugar as opposed to the approach you told about at the beginning of the video
In this example what he is doing is creating the Abstract Base Class (ABC) "Coffee" which is the only thing known to the client code! This means that the client/code should deal with implementation specific methods/properties of the ABC class Coffee (the Interface). So the client should not aware of any specific methods or properties assigned to any concrete classes of Coffee (e.g. Espresso). If you start relying on specific methods of concrete classes then you are coupling code which needs to be altered if the implementation changes for those methods, and hence is violating the Open/Closed principle. What you instead could do is having "private" methods inside Espresso which are called once public method(s) of the Coffee Interface is called (getDescription(...) or cost (...) in this example)
If this is not what you are looking for, then another design pattern could instead be appropriate, for example, Adapter Pattern or regular inheritance.
So to summarize, when creating a Coffee:
Coffee espresso = new Espresso()
or
Coffee java = new Java()
The code should only know that it is dealing with a Coffee, so you know that for each coffee instance you are able to call getDescription () and cost (). If you need to check the instance of the coffee whether it is an Espresso or Java, for example, to call specific methods/properties like getEspressoIngredients() (made up method). Then you are coupling your code to the concrete class Espresso, but what happenes if Espresso is taken off the menu? Then you need to change your code everywhere you are calling getEspressoIngredients(); which is violating open/closed principle and should be avoidable 😊
@@SuperSlugger94 No no, that's not what I meant. I know that Coffee is an abstract class and how we can use it. My point was that the expression "espresso = WithSugar(espresso)" is not useful because after the assignment we lose the specific parameters of the Espresso class.
Let's say, as you said, Espresso has its own method getEspressoIngredients, ok, and let's say I want to use the ingredients somehow and send the cup to a client. What do I do?
- I create the Espresso
- Put the sugar into it
- Get Espresso Ingredients
- Finally, send the cup to a client
Using the pattern I can't get Espresso Ingredients just because I put the sugar into it. That's the point. For some reason, putting the sugar into espresso doesn't allow me to use it as espresso without casting any longer. However, if I used the classic way that he mentioned at the beginning of the video with a method Add() I would be able to.
Speaking of the coupling to specific methods, we could use a function sendCoffee() which accepts Coffee, not Espresso, not breaking anything.
In addition, the statement "CoffeeDecorator is Coffee" doesn't sound good. My point isn't the pattern is bad but the example isn't good.
@@22222222222222223464 Yes, now I see what you mean! It is exactly as you say! If you need the concrete classes of Coffee to be very unique in the sense that they provide completely different behaviors, for example getEspressoIngredients() and getJavaBeanSize(), then as you say this pattern isn't really useful! When decorating a concrete class it again becomes of the thing you are decorating + additional behaviors (but only in the sense of the ABC Interface), the ABC Interface is the only thing you know that won't change when you are decorating something! All other methods specific to concrete classes (e.g Espresso and Java) will disapear once it is decorated with e.g addSugar(Espresso), so it won't be reachable unless explicitly casting.
So I see your point; in the scenario you are describing this pattern loses its purpose. However, if you only want to extend behaviors related to the ABC Interface then this pattern could be useful depending on your usecase.
Thank you so much!!