A list is still considered a hierarchical structure. It has a head (root), a tail (leaf), and potentially stuff in the middle. As you clearly stated, composite pattern is all about establishing the structure WITHOUT changing the underlying behavior of the component of the structure. Decorator is not about structure, but about changing (augmenting) the behavior of the component. Your example of decorator gave me an idea. In Rich Text Editors, text can be "decorated" with different styles like bolded, italicized, and underlined. It can also be decorated with color. It can also be decorated with font families. These decorations can be used in conjunction with each other. This sort of thing cannot (should not) be done using Composite Pattern. In the same context, Composite Pattern can be used to establish structures such as toolbars, menu bars, and even the document device context. This is important because (for instance) when you resize your Word Processor window, you will want to resize all of the children elements that belong to it (in order to keep the aspect ratio, for instance). This sort of functionality cannot (should not) be done with a Decorator Pattern. I think the confusion can be attributed in part (at least for me) to the fact that Decorator Pattern is categorized as a STRUCTURAL design pattern rather than BEHAVIORAL. I think this is a mistake because clearly the intent of the pattern is to add additional responsibilities (behaviors) to objects.
Hi, thanks for sharing your thoughts :) Just one correction @1:26 "at runtime alter the behavior of some particular thing" aligns more closely with the Strategy pattern rather than the Decorator pattern. Decorator pattern is about extending or enhancing the behavior of individual objects in a flexible way without modifying/altering their original base classes.
The exploration of tree structures in Composite and dynamic behavior modification in Decorator offers practical guidance for choosing the right pattern based on intent.
I've often found decorator very useful in game development. Works great with temporary boosts, score and timer multipliers, upgrades. Your videos are excellent
Hey Christopher, Thanks a lot for "this kind" of videos, it allows us to complete and verify our understanding of the related specialized design pattern video. As you've mentionned (between the lines) it's only when you compare some similar design patterns that you start realizing that it's all about nuances. Please keep explaining the nuances in similar DP, it's just VERY helpful, and sincerely good luck in your PhD :)
As I understood from the example, in composite all nodes will have same logic based on input from child-nodes. Whereas, in decorator each decorator-node may apply different logic on output from child decorator/component. Is above correct?
I like to think of decorator pattern as just adding (multiple) small functionality(ies) to the core logic of my object. But in composite pattern I think of it as "composing" multiple distinct functionality where each functionality has it's on identity. the composite object should not add functionality, It should compose the functionality of other objects in some what. (maybe apply all the changes once, maybe apply them in order or what ever). unlike decorators which have 1 and only 1 additional job to add.
Chris, you are doing great work...Keep it up!! One request from my end.....Please make videos on system design(architecture with design patterns for parking lot, whatsapp, or any system) so it will be really helpful..............
Thank you for watching and for your suggestion! Do you mean that you want more context? Like examples that are not just hypothetical but within a bigger context? Thank you again.
Any particular reason for discussing differences ...are't they for completely different needs..composite for structure and decorator for adding functionality...Could you give similarities..that would be interesting.
相同的是，装饰器与组合模式都继承并聚合抽象类（接口），但区别是，装饰器是抽象类，而组合composite是具象类 The same thing is that both the decorator and composition patterns inherit and aggregate abstract classes (interfaces), but the difference is that the decorator is an abstract class, while the composite is a concrete class.
Good Example I can think of for Composite pattern: perform totalEmployees operation on LDAP tree from different levels say Org level, Business unit level, Section, Dept, Group, leaf returning zero.
The basic definitions are the differences as you reiterated...Can following be the takeaway from this video?... Decorator is for applying multiple algorithm on single component... And Composite for applying single algorithm on multiple components(And subcomponents!!)... what do you say?
Your Design Pattern series is really helpful! Despite I have a GoF book, when I want to check new pattern I watch your video first. Do you plan to cover patterns not presented in GoF book?
I guess you could use a decorator tree for some kind of layered damage system in a game? first branches could be body parts and then each split layer could be a different type of armour and then the branches from that are over-armour / buffs? Might be a bit explodey but hey.
Great video! could you do more of these nuances? There is even a similarity between composite and proxy. Also, there is some nuances between Adaptor and decorator e.t.c perhaps more of higher level nuances like presented in this video will help us more. Great work Christopher. I am now a fan :D
Hi! Again, another great video. Could we say that another difference between patterns is that in Composite patterns the objective is that nodes have homogeneus functionalities while with the decorator we search for heterogeneus functionalities? Thanks a lot
What about the difference between the actual nodes of the two Patterns? i.e. in Decorator every node behaves differently. That's something you explicitly noted in the Decorator video bringing the example of Inputstream, Bufferstream etc. While in the Composite they all behave the same. Right? BTW thanks for the great videos!
i love your vids - even they are a little aged (but who cares as it is about patterns, that are there for a long time) - but this time i can't follow Component is an interface -> IComponent that has two concrete implementations: Leaf and Composite - while Leaf has no further children the Composite does. otherwise the decorator pattern the Component is an interface too -> IComponent that has a concrete implementation: ConcreteComponent and an abstract class Decorator that has multiple ConcreteDecorators i sense difference here - beyond intend ;)
A list is still considered a hierarchical structure. It has a head (root), a tail (leaf), and potentially stuff in the middle. As you clearly stated, composite pattern is all about establishing the structure WITHOUT changing the underlying behavior of the component of the structure. Decorator is not about structure, but about changing (augmenting) the behavior of the component.
Your example of decorator gave me an idea. In Rich Text Editors, text can be "decorated" with different styles like bolded, italicized, and underlined. It can also be decorated with color. It can also be decorated with font families. These decorations can be used in conjunction with each other. This sort of thing cannot (should not) be done using Composite Pattern.
In the same context, Composite Pattern can be used to establish structures such as toolbars, menu bars, and even the document device context. This is important because (for instance) when you resize your Word Processor window, you will want to resize all of the children elements that belong to it (in order to keep the aspect ratio, for instance). This sort of functionality cannot (should not) be done with a Decorator Pattern.
I think the confusion can be attributed in part (at least for me) to the fact that Decorator Pattern is categorized as a STRUCTURAL design pattern rather than BEHAVIORAL. I think this is a mistake because clearly the intent of the pattern is to add additional responsibilities (behaviors) to objects.
that was a good example! thanks.
Hi, thanks for sharing your thoughts :)
Just one correction
@1:26 "at runtime alter the behavior of some particular thing" aligns more closely with the Strategy pattern rather than the Decorator pattern. Decorator pattern is about extending or enhancing the behavior of individual objects in a flexible way without modifying/altering their original base classes.
The exploration of tree structures in Composite and dynamic behavior modification in Decorator offers practical guidance for choosing the right pattern based on intent.
I didnt even realize the similarity between the two patterns before watching this video. Thanks man!
I've often found decorator very useful in game development. Works great with temporary boosts, score and timer multipliers, upgrades. Your videos are excellent
First time I understood the difference between Decorator and Composite design pattern super clearly. :) Thank you so much.
Hey Christopher, Thanks a lot for "this kind" of videos, it allows us to complete and verify our understanding of the related specialized design pattern video. As you've mentionned (between the lines) it's only when you compare some similar design patterns that you start realizing that it's all about nuances.
Please keep explaining the nuances in similar DP, it's just VERY helpful, and sincerely good luck in your PhD :)
I like the way you explain the differences between the two patterns using references pointing upwards or downwards. Great work!
As I understood from the example, in composite all nodes will have same logic based on input from child-nodes. Whereas, in decorator each decorator-node may apply different logic on output from child decorator/component.
Is above correct?
I like to think of decorator pattern as just adding (multiple) small functionality(ies) to the core logic of my object.
But in composite pattern I think of it as "composing" multiple distinct functionality where each functionality has it's on identity.
the composite object should not add functionality, It should compose the functionality of other objects in some what. (maybe apply all the changes once, maybe apply them in order or what ever). unlike decorators which have 1 and only 1 additional job to add.
If I just could like the complete video series more than once...
Excellent content Christopher!
👍👍👍👍👍👍👍👍👍👍👍👍👍👍
Excellent video, as always, Christopher. I'm really enjoying this series. It's to just sit back watch you take these patterns apart. Cheers!
Chris, you are doing great work...Keep it up!! One request from my end.....Please make videos on system design(architecture with design patterns for parking lot, whatsapp, or any system) so it will be really helpful..............
Thank you for watching and for your suggestion! Do you mean that you want more context? Like examples that are not just hypothetical but within a bigger context? Thank you again.
Any particular reason for discussing differences ...are't they for completely different needs..composite for structure and decorator for adding functionality...Could you give similarities..that would be interesting.
Wow, it blew my mind!
I find your reasoning very interesting.
相同的是，装饰器与组合模式都继承并聚合抽象类（接口），但区别是，装饰器是抽象类，而组合composite是具象类
The same thing is that both the decorator and composition patterns inherit and aggregate abstract classes (interfaces), but the difference is that the decorator is an abstract class, while the composite is a concrete class.
装饰器是一对一，而组合模式一般都是一对多The decorator is one -to -one, and the combination mode is generally one to many
great explanation
Really Awesome
Good Example I can think of for Composite pattern: perform totalEmployees operation on LDAP tree from different levels say Org level, Business unit level, Section, Dept, Group, leaf returning zero.
Hey Cris...
Thanks for great work, however could you please create video on "Flyweight"
The basic definitions are the differences as you reiterated...Can following be the takeaway from this video?... Decorator is for applying multiple algorithm on single component... And Composite for applying single algorithm on multiple components(And subcomponents!!)... what do you say?
Your Design Pattern series is really helpful! Despite I have a GoF book, when I want to check new pattern I watch your video first. Do you plan to cover patterns not presented in GoF book?
I really like your videos 🔥🔥🔥
I guess you could use a decorator tree for some kind of layered damage system in a game?
first branches could be body parts and then each split layer could be a different type of armour and then the branches from that are over-armour / buffs?
Might be a bit explodey but hey.
GoF shows 1 Decorator in the diagram. See the last page of the book for the Class Diagram Notation. Arrow with no dot = one.
First and please continue sharing those videos ...
Great video! could you do more of these nuances? There is even a similarity between composite and proxy. Also, there is some nuances between Adaptor and decorator e.t.c perhaps more of higher level nuances like presented in this video will help us more. Great work Christopher. I am now a fan :D
Hi!
Again, another great video.
Could we say that another difference between patterns is that in Composite patterns the objective is that nodes have homogeneus functionalities while with the decorator we search for heterogeneus functionalities?
Thanks a lot
Tu gères poto!
What about the difference between the actual nodes of the two Patterns? i.e. in Decorator every node behaves differently. That's something you explicitly noted in the Decorator video bringing the example of Inputstream, Bufferstream etc. While in the Composite they all behave the same. Right? BTW thanks for the great videos!
i love your vids - even they are a little aged (but who cares as it is about patterns, that are there for a long time) - but this time i can't follow
Component is an interface -> IComponent that has two concrete implementations: Leaf and Composite - while Leaf has no further children the Composite does.
otherwise the decorator pattern
the Component is an interface too -> IComponent that has a concrete implementation: ConcreteComponent and an abstract class Decorator that has multiple ConcreteDecorators
i sense difference here - beyond intend ;)
Thanks, bro ! You have a beer, when we meet :)
Regards,
Aleksandar
Decorator that decorates the decorator that decorates the decorator that decorates the component 😀
if decorator must have a comp, its a composition not aggregation
Highly decorated lecture. let the viewer go and see the specific patterns , you could have done an on point session with