What is the Decorator Pattern? (Software Design Patterns)
HTML-код
- Опубликовано: 18 окт 2024
- In this video, learn why the Decorator Pattern is such an important design pattern. I tell you what the decorator pattern is, how it works, and explain it with an example.
Become a Better Developer Using the Courses I Recommend Below:
Master FAANG Coding Interviews - bit.ly/3CVgRN9
Learn AWS From Scratch - bit.ly/3gasoAm
Master Python here - bit.ly/3yJFJpI
Head First Design Patterns - amzn.to/36r8aJT
📚 MY RECOMMENDED READING LIST FOR SOFTWARE DEVELOPERS📚
Clean Code - amzn.to/37T7xdP
Clean Architecture - amzn.to/3sCEGCe
Head First Design Patterns - amzn.to/37WXAMy
Domain Driver Design - amzn.to/3aWSW2W
Code Complete - amzn.to/3ksQDrB
The Pragmatic Programmer - amzn.to/3uH4kaQ
Algorithms - amzn.to/3syvyP5
Working Effectively with Legacy Code - amzn.to/3kvMza7
Refactoring - amzn.to/3r6FQ8U
🎙 MY RECORDING EQUIPMENT 🎙
Shure SM58 Microphone - amzn.to/3r5Hrf9
Behringer UM2 Audio Interface - amzn.to/2MuEllM
XLR Cable - amzn.to/3uGyZFx
Acoustic Sound Absorbing Foam Panels - amzn.to/3ktIrY6
Desk Microphone Mount - amzn.to/3qXMVIO
Logitech C920s Webcam - amzn.to/303zGu9
Fujilm XS10 Camera - amzn.to/3uGa30E
Fujifilm XF 35mm F2 Lens - amzn.to/3rentPe
Neewer 2 Piece Studio Lights - amzn.to/3uyoa8p
💻 MY DESKTOP EQUIPMENT 💻
Dell 34 inch Ultrawide Monitor - amzn.to/2NJwph6
Autonomous ErgoChair 2 - bit.ly/2YzomEm
Autonomous SmartDesk 2 Standing Desk - bit.ly/2YzomEm
MX Master 3 Productivity Mouse - amzn.to/3aYwKVZ
Das Keyboard Prime 13 MX Brown Mechanical- amzn.to/3uH6VBF
Veikk A15 Drawing Tablet - amzn.to/3uBRWsN
Code: github.com/bea...
🌎 Find me here:
Twitter - / beabetterdevv
Instagram - / beabetterdevv
Patreon - Donations help fund additional content - / beabetterdev
#DesignPatterns
#DecoratorPattern
#SoftwareDesign
#SoftwareEngineer
![Chino Pacas - Modo Capone (with Drake & JOP) [Video Visualizador Oficial]](http://i.ytimg.com/vi/Zoc75M8Swhc/mqdefault.jpg)
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
Thank you. I finally understand what "Decorator" does.
Glad I could help!
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!
this gonna save me from this semester😍 very clear and informative, BIG THANKS🥂
You're very wecome Marckhycs!
Thank you. I was lost when I get into the code of getDescription() in Head First. And also your suggestions are awesome.
watched the first video and turned on the bell icon!
Thanks Himanshu and welcome!
Great voice! Good teaching!
Thankyou sir. I wish everybody would take the time to explain patterns like you.
Thank you! Working on a project for school and this helped a lot
lovely short and sweet explaination brother
Really good explanation!!
Thanks khomo!
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!
If the Decorator Pattern is extending functionality via composition rather than subclassing, shouldn't we have interfaces rather than abstract classes?
Thank you!
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());
}
Very good content. Congrats!!!!
Thank you so much 😀
Well done!
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?
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!
Thank you
Thanks a lot!
Nice video, thanks
You're very welcome Joaquin!
It's a recursive strategy - one class decorator has a reference to another class decorator.
shouldn't espresso extends coffee? since coffee is an abstract class and not an interface?
How can add mutilple functionlities dynamically? Like expresso withsugar and withMilk both..
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
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!
learned a lot, thanks!
Great to hear, thanks Yasahan!
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
great
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?
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!!