Here's a silly story I've made up to memorize and fit it all together 😁 On Fridays one guy likes to finish the day with a shot of plain rum, actually he used to distill it on his own, but that was too complicated process so he started buying bottles in a local shop, which is a great FACADE that removes all the complexity and pain of production process away from him. Couple months later he decides that plain rum is good but maybe it might taste better when DECORATED with lemon and other ingredients. But damn he's too lazy so he heads to a local bar. Apparently, that bar is a limited club, so in order to get in, he gotta know a friend who's already a club member (PROXY) who could tell the security he's cool enough to get in. The security guy is angry and just mumbles something, but our man happened to recognise some phrases in Spanish so he ADAPTED to the situation and replied in that language. That made the security guy smile so he happily allows this gringo to enter! Finally our man reaches out to the bartender who is standing behind the counter, which in fact resembles a BRIDGE between all of the party people and the bottles of various spirits on the shelves. And they all SHOUT OUT to Chris and wish him luck with his book :)
I can confirm that the bridge pattern is a natural conclusion, because I did it in my app the other week without knowing it's a pattern, and then watched your bridge pattern video the other day which pleasantly surprised me, since it means my design makes sense. In fact, it was even more or less the same example you used with different media types being used for the same UI components/widgets.
Hi Chris. Let me start by saying - great job!!! There's a small mistake in the UML of the decorator. A Decorator has a Component, and not as drawn in this video, i.e. a concrete decorator has a decorator, which simply misses the point of being able to decorate the core component.
Christopher, your teaching style is exceptional, and I truly appreciate the clarity and depth you bring to these complex concepts. Thank you so much for sharing your knowledge in such an engaging manner. The idea of you writing a book is incredibly exciting! It's definitely going to be an amazing contribution to the field. Looking forward to delving even deeper into these fascinating topics through your upcoming book.
It really amazes me how much of these discussed patterns really are things that we use often without even noticing. That being said, it is really important to sometimes sit down and define what they really mean and what they are applied for (or when they make the most sense). Great video as always, Christopher!
00:03 Comparison of structural patterns: bridge, adapter, decorator, proxy, and facade 02:02 Structural patterns like decorator and facade provide ways to simplify complex interactions. 06:15 Proxy pattern is used to control access to a real subject 08:19 Bridge pattern involves an abstraction and an implementer with multiple concrete implementations 12:21 The adapter pattern converts the interface of a class into another interface that the client expects. 14:32 Facade simplifies a complex subsystem, while Adapter adapts from one interface to another. 18:23 The proxy pattern provides a surrogate or a placeholder for another object to control access to it. 20:18 Proxy pattern is used to control access to a single thing, while decorator pattern is used to solve the problem of class explosion and treat different combinations of classes as a special case. 23:36 Structural patterns like Decorator and Proxy solve different problems. 25:23 The bridge pattern decouples an abstraction from its implementation. 29:10 Strategy pattern is about dependency injection 31:00 Bridge pattern is a flexible way of coupling classes using interfaces. 34:20 Facade pattern simplifies complex subsystems by providing a simpler interface. 35:50 The video discusses the importance of books in learning and working with object-oriented programming.
I gotta say...there are maybe 3 people who teach coding that I get a whole lot from. Jeffrey Way, Caleb Portzio, Luke Downing, and now you. You're a very good teacher my man
Binge watching the series... this was a very needed comparison between things that seemed related but nebulous before this instruction. Thanks for the lesson.
32:00 "Programming is discovered rather than invented", I really like that and helps a lot with understanding where these design patterns stem from. :)
Q: Dumb Questions Is it possible to create your own Design Patterns? Or is that something you have to be a “patterns guru” to do? A: First, remember that patterns are discovered, not created. So, anyone can discover a Design Pattern and then author its description; however, it’s not easy and doesn’t happen quickly, nor often. Being a “patterns writer” takes commitment. You should first think about why you’d want to - the majority of people don’t author patterns; they just use them. However, you might work in a specialized domain for which you think new patterns would be helpful, or you might have come across a solution to what you think is a recurring problem, or you may just want to get involved in the patterns community and contribute to the growing body of work. (c) Head First
It's always a pleasure to see youtube notifications saying you have posted new episode. This last one deals well with understanding differences with structural pattern. And as someone has already mentioned you should write a book about this subject. Thanks to your good sense of explanation it will surely be a success. +1
The way this guy trying to speak the unspeakable(i.e. underlying essence that only be get through experience) is mindblowing. only I watch what he want to covey.
I am pleased to hear that strategy pattern looks like half the bridge.. because it also is the conclusion that I came to. bridge is to my mind, a more generalized strategy pattern (as I commented in the bridge pattern video).
Fine tuning your moustache , hahaha!! :) Please please please cover the other patterns or atleast create a short video for each one having the basic explanation and an example. Thank you.
thanks Man your tutorial are very helpful . i statrd to read GOF befor this tutoral and i kind of got lost . after watched your vedios things start to make sence .. Thanks Bro !!
32:00 you probably mean Design Patterns are discovered rather than invented (not programming). Very good news to write a book about Design Patterns. I will be waiting for that book, you have a very special style of explaining the essence of Design Patterns.
I actually did mean "programming was discovered not invented". But then I was trying to say that perhaps the same goes for design patterns. Like if math was discovered, then anything we inductively prove using the axioms ought be considered discovered rather than invented. Similarly, if the axioms of programming was discovered, then anything we build using programming too ought to be discovered rather than invented. Sorry for not being clear. Sometimes even my thinking is sloppy :D Thanks for picking up the quote. It's a super interesting quote :)
Chris you can compare decorator and builder as well. for example in your decorator video the example coffee with condiments can be solved with a builder and I feel is more suited to be solved as a builder since it's more like a creational problem
I really appreciate your efforts. Thanks a lot. You mentioned composition when we inject something into a class. But I think it's aggregation, not composition. Because composition is when we create an instance in a class and cannot separate it.
Like the videos! If you could, maybe some code examples from the java core libraries that implement these patterns would be cool! For Example: Take Reader object from Files.IO package which can be decorated with a FileReader which can be decorated a BufferedReader; then explain the inner workings of the pattern! That would be cool!
Good point! Actually, exactly this example is the Head First book :) :) :) But about real world examples. I’ll try to make them an important part of the ebook :) A few others have requested more real examples as well. Thank you for your encouragement and feedback! :)
Thank you for your reply! My apologizes... my own mistake on the Reader Class; should be File Class decorated by FileReader... and so forth. All from the java.io package ;P duh
Hi Crish, really appreciate your efforts for all design patterns, in this comparison you didn't include Composite design pattern. It will be good to see all structural design patterns together.
Hi Chris, I found your channel a few days ago. On the GoF patterns, I should say the content is really good. Specially this video that compares all constructional patterns. It would be great if you do the same for creational and behavioral patterns as well. Thanks a lot. Babak
Are you familiar with functional programming ? Maybe ( Haskell programmers get it ) you can start a series on Functional Programming Design Patterns - starting maybe with the differences between the paradigms, with a couple of little programs written in both paradigms, and then move on to the patterns - Functors, Monads, State Monads, Co-Monads, Applicative Monads and so on and so forth. I really enjoy your channel, and will probably end up watching all your videos since im on a "OOP design patterns implementations" spree, taking a small break from FP.
Great news about your upcoming book on design patterns. Nice comparison between the all the structural patterns. And I was just thinking about the relation between Bridge and Strategy pattern when you introduced the UML diagrams of both to show the difference. You do read minds :P . Thank you!
Decorator UML seems to have small mistake ..abstract decorator should be have a component rather than concrete decorator having a component.. Correct me i am in wrong !! Keep going dude .. Keep doing.. Cheers!!!
Thank you for your explanation in the video. very easy to understand and comprehensive. I have 1 question about the Bridge design pattern. According to the UML there are 2 independent hierarchy in which let say Interface A has Interface B but indeed there are not any guarantees that A must have B inside (at least we have to ensure ourselves ), because A is an interface so we have not any mechanisms to do so ( please correct me if i am wrong). I am wondering what if i define Interface A and it has Not only B interface but also C,D,E,F .... and when i implement A , the implementation may have either B or C ,D or even 3 of them. so is it stil Bridge Pattern. how if A implementation does not have any B , C , D...
very good series sir , but i have a doubt regarding the decorator pattern , what if the arrangement matter to me like the problem you mentioned about addition and multiplication , what pattern should i use ?
Hi! Thanks for the great explanation as always :) I already ordered a copy of Head First book via your link, but if you do write a book in the end, I'll probably buy yours as well. Question: Would you be covering State Design Pattern any time soon? The info I find on the Internet or here on TH-cam is very confusing, and your explanation usually works wonders for me. Thanks again. Nurit.
For your book, will you consider including real world examples? I have a hard time groking things until I see it used in a manner that I can relate with.
I've been toying with the idea but it would make it so much more difficult to write :D So many pieces that need to match. But if that's what would make the most sense then I'll simply have to do it :)
I'll be glad to help out with real world examples that you can use in your book. I can already think of two interesting real world examples of the bridge pattern that I've used -- one as an existing API and the other in my line of work -- as well as the proxy pattern which will blow your mind! :D. All I ask for in return is that you remain awesome and help make my life awesome with a single line of reference. I'm pretty sure my next employer will be impressed (i.e. if I decide to go back to working in an organization).
I can think of a real world example for strategy pattern. Your system maintains information about Fixed Assets (such as a business's computers, vehicles, buildings, etc.) and they need to be depreciated. But there are various methods (algorithms) for calculating depreciation. So you have an IDepreciationStrategy interface and multiple classes that implement it, such as StraightLineDepreciationStrategy, DecliningBalanceDepreciationStrategy, SumOfYearsDigitsDepreciationStrategy, and UnitsOfProductionDepreciationStrategy. Then you have the the FixedAssets class contain an (Has-A) IDepreciationStrategy interface, and you use dependency injection at run time to determine which concrete depreciation class to pass in to perform the calculation. If you ever need a new method of calculating depreciation, you just create a new class that implements IDepreciationStrategy.
I'm not sure, but shouldn't be there dashed lines, when implementing an Interface? Like in the Proxy-Pattern? The two implementing classes R and P should have a dashed connection to S because of the dependency and not inheritance, shouldn't they? Nevertheless thanks for the comparison! Helped me a lot!
Don't know if anybody noticed it, but in Decorator pattern, the arrow should be drawn from Decorator interface up to its parent Component interface. Am I right or am I left ? At least GOF uses it like that. I'm not sure about the other book, as I don't have it. Thanks.
You are most definitely right! Excellent catch! There is a small correction in the video but I should probably have made more obvious. Thanks a lot for pointing it out though :) and sorry about any potential confusion I’ve caused!
Isnt the Strategy the same structurally as the Bridge pattern? In Strategy we had abstract Ducks and concrete Ducks as well as abstract behavior and concrete behavior :) But I agree that they are very different in intent
Hey man, I think for the decorator pattern, it's that AbstractDecorator has a AbstractComponent rather than a ConcreteDecorator has a AbstractDecorator.
Yikes. Sometimes I'm surprised by my stupidity :/ Double thanks! Corrected all of them. Even the amazon links were messed up too #facepalm. Thank you *very* much for the ping! :) :)
Seeing all 6 of those UML diagrams on one board is a great way to see just how different or similar the various patterns are.
I'm glad you think so :) That's sort of what I was thinking myself :) Thanks for watching!
Here's a silly story I've made up to memorize and fit it all together 😁
On Fridays one guy likes to finish the day with a shot of plain rum, actually he used to distill it on his own, but that was too complicated process so he started buying bottles in a local shop, which is a great FACADE that removes all the complexity and pain of production process away from him.
Couple months later he decides that plain rum is good but maybe it might taste better when DECORATED with lemon and other ingredients. But damn he's too lazy so he heads to a local bar. Apparently, that bar is a limited club, so in order to get in, he gotta know a friend who's already a club member (PROXY) who could tell the security he's cool enough to get in.
The security guy is angry and just mumbles something, but our man happened to recognise some phrases in Spanish so he ADAPTED to the situation and replied in that language. That made the security guy smile so he happily allows this gringo to enter!
Finally our man reaches out to the bartender who is standing behind the counter, which in fact resembles a BRIDGE between all of the party people and the bottles of various spirits on the shelves.
And they all SHOUT OUT to Chris and wish him luck with his book :)
Hahahha dude this is tooo good :) :) :)
This "story" should be pinned and referenced in Christopher's book. It happened really you know! :D
Too good a example Dude :)
Christopher made design patterns look so easy that people are able to come up with stories
@@betterculture wow, I'm so glad to hear that) that's the power of community ♥️
I can confirm that the bridge pattern is a natural conclusion, because I did it in my app the other week without knowing it's a pattern, and then watched your bridge pattern video the other day which pleasantly surprised me, since it means my design makes sense. In fact, it was even more or less the same example you used with different media types being used for the same UI components/widgets.
Hi Chris. Let me start by saying - great job!!! There's a small mistake in the UML of the decorator. A Decorator has a Component, and not as drawn in this video, i.e. a concrete decorator has a decorator, which simply misses the point of being able to decorate the core component.
Christopher, your teaching style is exceptional, and I truly appreciate the clarity and depth you bring to these complex concepts. Thank you so much for sharing your knowledge in such an engaging manner.
The idea of you writing a book is incredibly exciting! It's definitely going to be an amazing contribution to the field. Looking forward to delving even deeper into these fascinating topics through your upcoming book.
The decorator pattern UML has a small problem. The D has C instead of CD has D.
why are u watching lol
Yes, spotted the same.
I was just about to write this lol.
qFDGEOFGJerljgopergerjgoernglerjogrg - Yes.
Pro trick: you can watch series on Flixzone. Been using it for watching all kinds of movies recently.
It really amazes me how much of these discussed patterns really are things that we use often without even noticing. That being said, it is really important to sometimes sit down and define what they really mean and what they are applied for (or when they make the most sense). Great video as always, Christopher!
00:03 Comparison of structural patterns: bridge, adapter, decorator, proxy, and facade
02:02 Structural patterns like decorator and facade provide ways to simplify complex interactions.
06:15 Proxy pattern is used to control access to a real subject
08:19 Bridge pattern involves an abstraction and an implementer with multiple concrete implementations
12:21 The adapter pattern converts the interface of a class into another interface that the client expects.
14:32 Facade simplifies a complex subsystem, while Adapter adapts from one interface to another.
18:23 The proxy pattern provides a surrogate or a placeholder for another object to control access to it.
20:18 Proxy pattern is used to control access to a single thing, while decorator pattern is used to solve the problem of class explosion and treat different combinations of classes as a special case.
23:36 Structural patterns like Decorator and Proxy solve different problems.
25:23 The bridge pattern decouples an abstraction from its implementation.
29:10 Strategy pattern is about dependency injection
31:00 Bridge pattern is a flexible way of coupling classes using interfaces.
34:20 Facade pattern simplifies complex subsystems by providing a simpler interface.
35:50 The video discusses the importance of books in learning and working with object-oriented programming.
I gotta say...there are maybe 3 people who teach coding that I get a whole lot from. Jeffrey Way, Caleb Portzio, Luke Downing, and now you. You're a very good teacher my man
Are all those mentioned TH-camrs?
This is a remarkable effort to help anyone getting the concepts right away with such simplicity and ease. Thanks!
One of the best video comparing Structural Patterns on youtube today - Thanks mate.
wow -- this video is just great, especially sort of seeing the bridge pattern as a more general form as strategy pattern
Binge watching the series... this was a very needed comparison between things that seemed related but nebulous before this instruction. Thanks for the lesson.
Super interesting video for me. I think it's the first time I actually understand many of these patterns. Thank you!
With this comparison, I realized that the abstract decorator is a proxy for the concrete component.
Super series! Thanks. Waiting for the next one.
I got a habit of saying 'SUPER' before everything. You are super talented.
Thanks for this series :)
32:00 "Programming is discovered rather than invented", I really like that and helps a lot with understanding where these design patterns stem from. :)
I don't know how to say that But I Just want to appreciate you for making this playlist, Its awesome
This comparison video is very helpful to identify and choose the most suitable pattern for a specific problem.
Videos like this are really helpful because they also help to do a quick revision of previous concepts.
Q: Dumb Questions
Is it possible to create your own Design Patterns? Or is that something you have to be a “patterns guru” to do?
A: First, remember that patterns are discovered, not created. So, anyone can discover a Design Pattern and then author its description; however, it’s not easy and doesn’t happen quickly, nor often. Being a “patterns writer” takes commitment.
You should first think about why you’d want to - the majority of people don’t author patterns; they just use them. However, you might work in a specialized domain for which you think new patterns would be helpful, or you might have come across a solution to what you think is a recurring problem, or you may just want to get involved in the patterns community and contribute to the growing body of work.
(c) Head First
excellent teaching......!! i'm still in shock how easily u covered all the points of them
It's always a pleasure to see youtube notifications saying you have posted new episode. This last one deals well with understanding differences with structural pattern. And as someone has already mentioned you should write a book about this subject. Thanks to your good sense of explanation it will surely be a success.
+1
decorator: add function, multi-function, so that there will not be a lot of classes
proxy: assess control
bridge: two hierarchy, injection B into A
The way this guy trying to speak the unspeakable(i.e. underlying essence that only be get through experience) is mindblowing.
only I watch what he want to covey.
I am pleased to hear that strategy pattern looks like half the bridge.. because it also is the conclusion that I came to.
bridge is to my mind, a more generalized strategy pattern (as I commented in the bridge pattern video).
Thank you very much Christopher, this serie helped me very much in my career
wuahhhh, this is what it feels like to be taught by the best professor ~
Fine tuning your moustache , hahaha!! :) Please please please cover the other patterns or atleast create a short video for each one having the basic explanation and an example. Thank you.
:) :) :) :) Thank you very much for your encouragement :)
thanks Man your tutorial are very helpful . i statrd to read GOF befor this tutoral and i kind of got lost . after watched your vedios things start to make sence .. Thanks Bro !!
32:00 you probably mean Design Patterns are discovered rather than invented (not programming). Very good news to write a book about Design Patterns. I will be waiting for that book, you have a very special style of explaining the essence of Design Patterns.
I actually did mean "programming was discovered not invented". But then I was trying to say that perhaps the same goes for design patterns. Like if math was discovered, then anything we inductively prove using the axioms ought be considered discovered rather than invented. Similarly, if the axioms of programming was discovered, then anything we build using programming too ought to be discovered rather than invented. Sorry for not being clear. Sometimes even my thinking is sloppy :D Thanks for picking up the quote. It's a super interesting quote :)
Also, thanks for pushing for the book. I'm glad to hear that it would be interesting :)
Love from India. Great explanation. Thank you
Wow! You are my favourite teacher, bro :)
Now I am ready to finish my project.
Thank you!
I hope you are one of my teacher in programming, your awesome🔥
Thanks for all videos. Here comparison of strategy and bridge was very interesting to me.
Chris you can compare decorator and builder as well. for example in your decorator video the example coffee with condiments can be solved with a builder and I feel is more suited to be solved as a builder since it's more like a creational problem
Very Good comparing between the strategy pattern and bridge pattern.
I really appreciate your efforts. Thanks a lot. You mentioned composition when we inject something into a class. But I think it's aggregation, not composition. Because composition is when we create an instance in a class and cannot separate it.
Me: Where will our study of design patterns lead us?
Christopher: Dependency injection into madness!!!!
33:00
Another Great video, Thanks for sharing, I really appreciate your job
Happy new year Chris .
Thank you for all the efforts .
Keep going bro , say my hi to your cat 😉
Like the videos! If you could, maybe some code examples from the java core libraries that implement these patterns would be cool! For Example: Take Reader object from Files.IO package which can be decorated with a FileReader which can be decorated a BufferedReader; then explain the inner workings of the pattern! That would be cool!
Good point! Actually, exactly this example is the Head First book :) :) :) But about real world examples. I’ll try to make them an important part of the ebook :) A few others have requested more real examples as well. Thank you for your encouragement and feedback! :)
Thank you for your reply! My apologizes... my own mistake on the Reader Class; should be File Class decorated by FileReader... and so forth. All from the java.io package ;P duh
Really awesome videos!, Waiting for rest of the design pattern videos..hope you will cover those soon
Supernice! Waiting for the others. And for a comparison of the factory and the builder.
Thanks for plus 1:ing more comparison videos. I'm glad the format was useful :)
Hey Chris, Thank you so much for this helpful and great series. Waiting eagerly for the next video.
Hi Crish, really appreciate your efforts for all design patterns, in this comparison you didn't include Composite design pattern. It will be good to see all structural design patterns together.
how are you ammmmazing like this ,thank you very very very much for this series , it is realy so cool😍😍😍😍
Just brilliant, as always, natural mentor and teacher :)
Super awesome! I have been waiting for this episode.
Glad to hear. Thanks for sticking around :)
Wow. You are a phenomenal teacher. Amazing! Thank you.
Thanks, you make me a better developer.
Great stuff! I would for sure buy your book linking the concepts together.
Comparison videos are always welcomed
Hi Chris,
I found your channel a few days ago. On the GoF patterns, I should say the content is really good. Specially this video that compares all constructional patterns. It would be great if you do the same for creational and behavioral patterns as well.
Thanks a lot.
Babak
These videos are so adictive 😁😁. Thanks for your effort 🤓
Are you familiar with functional programming ? Maybe ( Haskell programmers get it ) you can start a series on Functional Programming Design Patterns - starting maybe with the differences between the paradigms, with a couple of little programs written in both paradigms, and then move on to the patterns - Functors, Monads, State Monads, Co-Monads, Applicative Monads and so on and so forth. I really enjoy your channel, and will probably end up watching all your videos since im on a "OOP design patterns implementations" spree, taking a small break from FP.
good comparison between bridge and decorator!!!
Amazing explanation of bridge pattern, just awesome! thanks)
I think Facade is very useful for libraries that are complex bcs it has more solutions than you actually need.
Tried to use it for my micro-libraries even before i hear about GoF Patterns, so yeah)
the empty sub set can be implemented as null object pattern🤓
great videos!
Great news about your upcoming book on design patterns. Nice comparison between the all the structural patterns. And I was just thinking about the relation between Bridge and Strategy pattern when you introduced the UML diagrams of both to show the difference. You do read minds :P . Thank you!
Awesome. I'm happy to accommodate :) Thank you for watching and for the very kind comment :)
Decorator UML seems to have small mistake ..abstract decorator should be have a component rather than concrete decorator having a component.. Correct me i am in wrong !! Keep going dude .. Keep doing.. Cheers!!!
In decorator pattern, it is also important the order of the decorators, not just which
Absolutely great video! Definitely would like to get your book.
Great As always, thank you Chris
+Krzysztof Romanowski Thanks :)
Excelente video, gracias por la explicacion.
awesome comparison!
Thank you for your explanation in the video. very easy to understand and comprehensive. I have 1 question about the Bridge design pattern. According to the UML there are 2 independent hierarchy in which let say Interface A has Interface B but indeed there are not any guarantees that A must have B inside (at least we have to ensure ourselves ), because A is an interface so we have not any mechanisms to do so ( please correct me if i am wrong). I am wondering what if i define Interface A and it has Not only B interface but also C,D,E,F .... and when i implement A , the implementation may have either B or C ,D or even 3 of them. so is it stil Bridge Pattern. how if A implementation does not have any B , C , D...
Excellent explained! Thank you so much!!!
Comparing similarities would be nice too
As accessible as ever ... thanks!
Glad to hear! Remember to let me know if I start to get lazy :) Thanks for watching :)
You did a great job Ostad, keep it up ;)
very good series sir , but i have a doubt regarding the decorator pattern , what if the arrangement matter to me like the problem you mentioned about addition and multiplication , what pattern should i use ?
Hi Chris, awesome class
please explain Compisite Pattern
thanks
Boy, that was good! Thanks Chris!
Excellently explained....
Waiting for more videos on design patterns.
excellent strategy to explain....
Thanks. I’m glad to hear :) Thanks for watching :)
Hi! Thanks for the great explanation as always :)
I already ordered a copy of Head First book via your link, but if you do write a book in the end, I'll probably buy yours as well.
Question: Would you be covering State Design Pattern any time soon?
The info I find on the Internet or here on TH-cam is very confusing, and your explanation usually works wonders for me.
Thanks again.
Nurit.
Awesome job! Thank you
For your book, will you consider including real world examples? I have a hard time groking things until I see it used in a manner that I can relate with.
Great idea, this will be very helpful
I've been toying with the idea but it would make it so much more difficult to write :D So many pieces that need to match. But if that's what would make the most sense then I'll simply have to do it :)
I'll be glad to help out with real world examples that you can use in your book. I can already think of two interesting real world examples of the bridge pattern that I've used -- one as an existing API and the other in my line of work -- as well as the proxy pattern which will blow your mind! :D. All I ask for in return is that you remain awesome and help make my life awesome with a single line of reference. I'm pretty sure my next employer will be impressed (i.e. if I decide to go back to working in an organization).
I can think of a real world example for strategy pattern. Your system maintains information about Fixed Assets (such as a business's computers, vehicles, buildings, etc.) and they need to be depreciated. But there are various methods (algorithms) for calculating depreciation. So you have an IDepreciationStrategy interface and multiple classes that implement it, such as StraightLineDepreciationStrategy, DecliningBalanceDepreciationStrategy, SumOfYearsDigitsDepreciationStrategy, and UnitsOfProductionDepreciationStrategy. Then you have the the FixedAssets class contain an (Has-A) IDepreciationStrategy interface, and you use dependency injection at run time to determine which concrete depreciation class to pass in to perform the calculation. If you ever need a new method of calculating depreciation, you just create a new class that implements IDepreciationStrategy.
I'm not sure, but shouldn't be there dashed lines, when implementing an Interface? Like in the Proxy-Pattern? The two implementing classes R and P should have a dashed connection to S because of the dependency and not inheritance, shouldn't they?
Nevertheless thanks for the comparison! Helped me a lot!
That's cool. Thanks!
Don't know if anybody noticed it, but in Decorator pattern, the arrow should be drawn from Decorator interface up to its parent Component interface. Am I right or am I left ? At least GOF uses it like that. I'm not sure about the other book, as I don't have it. Thanks.
You are most definitely right! Excellent catch! There is a small correction in the video but I should probably have made more obvious. Thanks a lot for pointing it out though :) and sorry about any potential confusion I’ve caused!
Thanks, This is Amazing!
Isnt the Strategy the same structurally as the Bridge pattern? In Strategy we had abstract Ducks and concrete Ducks as well as abstract behavior and concrete behavior :) But I agree that they are very different in intent
superb, you are champion.
A big thank you
Thank you! :)
Great videos, thanks it's of great help :)
great video!
great one!!!!!!!! keep it up!!!!!!
@
Christopher thanks again for your magic, any news about your book?
Hi , thx for really helpful videos .
Does repository pattern exist in your todos ? :)
very helpful, thanks
Hey man, I think for the decorator pattern, it's that AbstractDecorator has a AbstractComponent rather than a ConcreteDecorator has a AbstractDecorator.
Hey Chris, there're some numeration shenanigans going on, it shouldn't be Episode 5. Btw link to the playlist is messed up in the description.
Yikes. Sometimes I'm surprised by my stupidity :/ Double thanks! Corrected all of them. Even the amazon links were messed up too #facepalm. Thank you *very* much for the ping! :) :)
Don't sweat it, you are the best! 😄
very very good, learn at the same time patterns and technical English to explain them. I signed up
Can you share the same comparisons video for behavioral and Creational Design patterns.