I would add a point that "variations in behavior" can also come from _outside_ the class - a class can just be a data type, without being responsible for all the ways the data will be used. Imagine an Attack subtype, EnergyAttack, which has an additional property EnergyType. Now Scratch is a base Attack instance, and Thunderbolt is an EnergyAttack (with EnergyType = Lightning). Looking at just the class definitions, you could say this is a data-only variation, but it makes sense because the change is in the data structure (an additional property), not just values. These subclasses may or may not implement variations in behavior themselves, but _allow for_ external variations by being different types: We may have many general functions that work with the Attack type, as well as some functions that accept EnergyAttack specifically and work with the EnergyType property.
Have been watching your Design Patterns series and the code walks videos and was always thinking if I ever wanted to have a youtube channel it would have been of this style. If only he was back. Wish granted, welcome back, so happy to see notifications from you! :DDDD
Oh my god. I used to watch your videos when I started learning programming in 2021. Right now, I have an interview with Google scheduled next week. You don't know how happy I am to see you back. Thanks for coming and welcome back :)
I didn't learn anything, but the way you described the information in the video *clarified* what I'd already known -if that makes sense. You are excellent at explaining things in very clear terms, and I appreciate that. Subbed.
Last month i was discussing with my friend about Design patterns and in that discussion i recommended him your channel. While discussing i said to him that don't know why you aren't posting any content. I was little bit worried about you. Now i am very glad to see you back. 🥳🥳🎉🎉❤❤❤
I've been watching your playlists whilst working on my project over the last year, and this video is so relevant to what I'm currently working on, and exactly what I've been asking myself while working on my current systems. Being self taught I don't know the theory very well, so I would had never known that I was dealing with 'sub-type polymorphism'. Good to know I've been going down the right path, and also to know what it's called!
I started watching him on thursday, fell in love in his way of teaching, and was thrilled when saw that last video was posted 3 years ago. And now he appears out of nowhere 😂 If you were giving lectures on my Uni, i wouldnt miss a single one
Your knowledge is actually so precious. I love the fact that you just use concepts with whiteboard. Thank You for coming back to us, You can make a lot of us promote with your videos!
Good stuff. There are solutions without subtypes though. 1. The example as stated could have `Move` that accepts a `name` as well as the individual effects. `new Move(name, healthEffect, armorEffect)` So attack would be `new Move('attack', -50, 0)` I'd only start packing in parameters in a language with named parameters though. 2. You could have a method to add effects to a move as a fluent interface `addEffect(property, amount)` `new Move('heal').addEffect('health', 50).addEffect('armor`, 50). `Use` would just apply those effects to the target. Of course you'd need to do something about validating target properties. 3. Still polymorphic, but passing a `use` function to the constructor of a `Move` class `new Move('attack', attackFunction) keeps your class hierarchy flat and allows you to define any behavior you want in the passed function. Do we really need an interface and subclasses? Maybe. Maybe not. Different behavior is just the first condition. For the subtype with polymorphism solution, that behavior has to be complex enough that it's simpler to extend. Class hierarchies add overhead / cognitive load. You need to be gaining enough from the strategy to offset that. This depends on a lot of things. The behaviors, how broad the set needs to be, how its expected to grow, even the language you're writing.
Yeah, like, I think I'd just declare a simple struct with the effect data and pass it in, and expand it as things go (including "no effect" defaults so things don't break). If it does grow enough that this gets cumbersome, by then I'd have a better picture of what actually matters. Probably would still avoid subclasses tho : p
From last week I started watching your Design Pattern playlist and thinking why Chris stopped posting videos for last 3 years. To my surprise there was a notification😮. Your teaching is so great and natural, not everyone gets so easily. Keep up the Great work!
Once again, you enlightened me about something that might seen implicitly known and simple but in reality a truly good software engineer needs to be absolute aware of.
Your Design pattern playlist is the best I have ever seen on any channel/courses. It was about a year ago I started and completed the DP videos, but was disappointed to see no more , and randomly today this video pops up on my feed, very happy to see you again hopefully you will complete the rest of the patterns too 😊. I tried connecting you on LinkedIn too but it was restricted I think 😅.
Previously, thank you for the knowledge, and welcome back. What I get from the explanation is: We should/must prefer to be implicit about a specific type of data that has the same structure and behavior, instead of being explicit (where we define it based on the actual concept or domain) about that type (CMIW).
WHOA! i started watching your pattern videos like a week ago, binging them while at the gym, while taking walks, etc. i was like "eh it's been a long time since hes posted...he was a good teacher" and then here you are!!
Whoa, seeing you in my sub box is not something i expected today. Long time viewer of the channel, since the ramda days! Good to see you back. Your channel helped me get into functional programming, and now i'm absolutely obsessed. Do you have any plans for more FP related videos?
Its always better to create a video for a problem than to create one for a video. Thank you for this video, polymorphism is used very frequently without much thought given 😢
Good video. I retired from software development years ago. I wrote some fairly complex systems and I used polymorphism at times. Much of it had to do with the implementation of corporate business rules. An example was doing 'credit checks' of customers. The calling system simply wanted a 'yes/no' credit check. However, HOW the credit check was executed was different depending on the kind of customer being checked. There were many different kinds of customers with different histories. The company had different rules and methods for each. Some required a simple database lookup while others required remote access to third-party systems. Using polymorphism the different rules could be independently developed and "bolted on" to the system. So as per your terminology this was very much different behavior.
I was literally googling for your name yesterday to know what are you up to these days and suddenly your new video pops up after 3 years. Thank you for sharing knowledge with us. You’re an amazing teacher!
Once you separate models from behaviour classes (highly recommended) this issue is then about model abstractions. Model abstraction can be handled with composition rather than inheritance. Behaviour abstractions occur everywhere of course, you have many things that can do the same job. The question then becomes, does a model abstraction add any value to my behaviours? Model composition is still fragile, model interfaces will be more stable. If your code operates on disparate models you need it or mappers (a behaviour form of an interface!). If I define a feature for my app I can expose the interface that I expect to make my component completely self contained. If I write templates or generics it's normal to have a requirement of your that is an interface. The design consideration is a good one, it highlight lots of bad designs, but you haven't come full circle yet!
omg great to see u again! Ur videos has helped me tremendously during my time at chalmers, and im actually now TEACHING the same course i used ur videos to pass years before! Will recommend ur channel to all my students!
Kul att se att du är tillbaka igen! Dina förklaringar av designmönster hjälpte mig enormt under skoltiden. 👍 Man önskade att fler lärare var såhär pedagogiska.
I am determined to watch this video as many times as it takes to understand what he is talking about. 10 times later, maybe I should watch a refresher on polymorphism.
Welcome baaaaack!!!!!!!!! Happy to see you around after so much time! Hope you'll stay for a while, your content and way of explaining things are precious.
Thanks for sharing your valuable knowledge again. Your videos about design patterns helped me a lot when I landed my first job as a software developer. I hope 🤞 you don’t give a break anymore 😊
Welcome back, I have missed your content, it is great. Your analysis has been vital to my programming evolution, if only I'd have had teachers with your energy.
It all depends if you need to lift data to the type level. If Thunderbolt and Scratch are "dummy data" or "metadata" (basically hold no meaning) for your application, then sure, represent them through the Attack class. If your application does or will variate its behavior based on one or the other, expressing them as types might be advantageous. But I can still see teams deciding to go with conditionals and not introducing explicit types (if, e.g., the types introduced are not actually stable in the long term).
Another point is that if you can treat moves as data then you can also easily load them in (possibly even hot-load them in), so changing a move's behavior during development, balancing, testing, etc, can be as easy as changing a value in, say, a json file, which is just so convenient.
you did really well with this video, i was able to flip into it and out of it, while just listening and you never lost me. i now know what you put into this video and thats always nice!
Yes, I completely agree that you should use polymorphism when dealing with varying behaviors. However, if you need variations in data and want to limit the number of such variants, you can employ the factory method pattern. For instance, you can create a class called Attack with a private constructor. Then, add two static methods-thunderbolt and scratch-to control the initialization and ensure that no incorrect variants are created.
got randomly recommended this by the youtube algorithm, thought it was going to be about types because of the title (as in, type theory), but it seems to be about some object oriented language (not even clear which one), but was interesting to watch!
Where were u man. I recently found(1.5 weeks ago) ur channel and always thought wht happened to this guy becoz u r such a good teacher .Last video ws 3 yrs ago. I then started studying design patterns using ur videos. I completed 15 of it going to complete it by tomorrow and u came back. I think u were waiting for me to complete 15 videos😂
I think a major complexity concern with the "wrong" use of polymorphism is the possibility of type explosion. If there's a small number of implementations, I don't think it's such a big issue to use subtyping even when you only have variation in data. Granted, it's more complex than it needs to be, like you mention. But this is complexity in terms of code. Conceptually, it feels more straight-forward to me to have a "Thunderbolt" type and a "Scratch" type rather than just a generic "IAttack" that you need to configure at instantiation. Giving things names helps organize the program, and few names are more powerful than types in this regard. The parameterized class approach is more flexible too, I agree, but I think there is almost always a cost associated with flexibility. In this case, I think it introduces some additional cognitive load, because you are in some sense working at a lower level of abstraction (even though IAttack is more abstract than Thunderbolt, you need to contend with the implementation detail of the attack value when instantiating a "Thunderbolt" in this case; using polymorphism instead neatly encapsulates this). If we don't use polymorphism here, it feels like some kind of factory (method?) would be in order instead. Something to somehow reify these concepts of "Thunderbolt" and "Scratch". This also brings up the debate of: should you always go with the simplest possible solution that solves the problem as it is currently understood?. Or should you plan for some amount of future change? What amount and what kinds of change are we justified to plan for? Because one could reasonably predict your middle example evolving in the direction of the last example.
I've worked with code that has the opposite problem of type explosion. In this case, instead of defining an interface for, say, a drawing object with a draw() method, then subclassing the drawing object class with classes for doing lines, text, rectangles, and 50 other drawing operations, the designers used one class that had all the data required to draw anything, with 53 different constructors that take a type parameter and the type specific data, with a single draw function that used a switch statement to decide what actual drawing code to use. Totally miss the point of OOP much? It was the textbook definition of a C programmer who uses a C++ compiler and calls himself a C++ expert. The worst part was that he was teaching the junior guys how to write good code. Not long after I was asked to make this monstrosity work, I left the company.
@@alamaralaaThat sounds painful for sure, and worse than type explosion. What was the saying? "The 2 hardest problems in programming are naming things and off-by-one errors"? The "naming things" part to me encapsulates more than just picking the names of your components, it also implies deciding which components you should have. And that's the really hard part. Picking the right abstractions. One might say this guy didn't abstract at all, but I don't think that's right. You can't _really_ solve a problem of significant complexity without at least some sort of abstraction. He just ended up choosing all the wrong ones. Definitely sucks for anyone who has to work with them, but I empathize with struggling to abstract well.
He randomly came back after three years! Tak! Good to see you again.
Yessssss I'm glad he is back man, I've learned so many things important on my career because of his videos
Love him, jest super
OMG I can't believe this, I asked him last week on Twitter when he is coming back..and here he is. 🐐
What are the chances he’ll stay with us for some time now 😅
@@mr_archangerdepends if project manager leaves him alone
Finally he remembered his password
🤣🤣
called it!! 😂
Where you were?, will you make video contunue now@@ChristopherOkhravi
This must have been some variation in data.
I like to think, that you got so annoyed by someone at work using subtype polymorphism the wrong way, that it brought you back here ;)
I teach at a university so I read a lot of student code 😉
in which university do you teach I need to attend there, you're a CS legend
@@ChristopherOkhravi
I wish more people in your team do things in wrong way that you make more videos to teach others 😂
literally just watched your design patten playlist, thinking why hasn't he posted for 3 years. perfect timing
Man, your notification popping up is the best thing happened in months❤, please don't disappear again :)
Welcome back! Got a huge amount of value out of this channel in my early days of becoming a dev
I've never been more engaged with software engineering UA-cam content. Your presentation skills are excellent.
I would add a point that "variations in behavior" can also come from _outside_ the class - a class can just be a data type, without being responsible for all the ways the data will be used. Imagine an Attack subtype, EnergyAttack, which has an additional property EnergyType. Now Scratch is a base Attack instance, and Thunderbolt is an EnergyAttack (with EnergyType = Lightning). Looking at just the class definitions, you could say this is a data-only variation, but it makes sense because the change is in the data structure (an additional property), not just values. These subclasses may or may not implement variations in behavior themselves, but _allow for_ external variations by being different types: We may have many general functions that work with the Attack type, as well as some functions that accept EnergyAttack specifically and work with the EnergyType property.
Have been watching your Design Patterns series and the code walks videos and was always thinking if I ever wanted to have a youtube channel it would have been of this style. If only he was back. Wish granted, welcome back, so happy to see notifications from you! :DDDD
I didnt even fully read the title, I just saw the thumbnail and clicked. Welcome back good sir.
Suddenly you appeared out of thin air, please be consistent. Love your content.
No one told you to wait
we aint entitled to his time
He can post whenever he feels like posting. How entitled are you. Anyway thanks for the content ignore comment like above
I came to the comments section to share my excitement about your return.
But, wow, I didn't expect there to be so many of us!
Oh my god. I used to watch your videos when I started learning programming in 2021. Right now, I have an interview with Google scheduled next week. You don't know how happy I am to see you back. Thanks for coming and welcome back :)
Glad to hear 😊 Best of luck on your interview!
I didn't learn anything, but the way you described the information in the video *clarified* what I'd already known -if that makes sense.
You are excellent at explaining things in very clear terms, and I appreciate that. Subbed.
I'm very happy to hear that. Also, thank you for the sub. Welcome 😊
Your teaching is the greatest and simpler....❤
Last month i was discussing with my friend about Design patterns and in that discussion i recommended him your channel. While discussing i said to him that don't know why you aren't posting any content. I was little bit worried about you. Now i am very glad to see you back. 🥳🥳🎉🎉❤❤❤
I've been watching your playlists whilst working on my project over the last year, and this video is so relevant to what I'm currently working on, and exactly what I've been asking myself while working on my current systems. Being self taught I don't know the theory very well, so I would had never known that I was dealing with 'sub-type polymorphism'. Good to know I've been going down the right path, and also to know what it's called!
I watch your videos and you are the first teacher whoes course i can buy without thinking about money.
Awesome to see you back Chris! I’ve learned a lot from your videos, and have always enjoyed hearing your perspective on things. 😎👍
Word to mother....ur design patterns videos helped me nail an interview in 2017 🤣🤣🤣. Now I'm a Lead software engineer. Thanks
I started watching him on thursday, fell in love in his way of teaching, and was thrilled when saw that last video was posted 3 years ago. And now he appears out of nowhere 😂 If you were giving lectures on my Uni, i wouldnt miss a single one
I like this format. My ADD was trying its best to block the info, but this guy just kept going :)
Your knowledge is actually so precious. I love the fact that you just use concepts with whiteboard. Thank You for coming back to us, You can make a lot of us promote with your videos!
Thank you very much for sharing 😊😊
Good stuff. There are solutions without subtypes though.
1. The example as stated could have `Move` that accepts a `name` as well as the individual effects.
`new Move(name, healthEffect, armorEffect)`
So attack would be `new Move('attack', -50, 0)`
I'd only start packing in parameters in a language with named parameters though.
2. You could have a method to add effects to a move as a fluent interface
`addEffect(property, amount)`
`new Move('heal').addEffect('health', 50).addEffect('armor`, 50).
`Use` would just apply those effects to the target. Of course you'd need to do something about validating target properties.
3. Still polymorphic, but passing a `use` function to the constructor of a `Move` class
`new Move('attack', attackFunction) keeps your class hierarchy flat and allows you to define any behavior you want in the passed function. Do we really need an interface and subclasses? Maybe. Maybe not.
Different behavior is just the first condition. For the subtype with polymorphism solution, that behavior has to be complex enough that it's simpler to extend. Class hierarchies add overhead / cognitive load. You need to be gaining enough from the strategy to offset that. This depends on a lot of things. The behaviors, how broad the set needs to be, how its expected to grow, even the language you're writing.
Yeah, like, I think I'd just declare a simple struct with the effect data and pass it in, and expand it as things go (including "no effect" defaults so things don't break). If it does grow enough that this gets cumbersome, by then I'd have a better picture of what actually matters.
Probably would still avoid subclasses tho : p
From last week I started watching your Design Pattern playlist and thinking why Chris stopped posting videos for last 3 years. To my surprise there was a notification😮. Your teaching is so great and natural, not everyone gets so easily. Keep up the Great work!
Great to see you again Christopher. Miss your videos of design patterns and discussions about principles. Welcome Back!!
Once again, you enlightened me about something that might seen implicitly known and simple but in reality a truly good software engineer needs to be absolute aware of.
Happy to see you upload after 3 years love the way you teach..
So happy to see you back. You're the sole educator whose UA-cam videos I choose to view at regular speed, even when they extend to an hour.
Thanks for your work, I got a masters in software engineering 2 years ago and your videos on the design patterns really helped me.
Your Design pattern playlist is the best I have ever seen on any channel/courses. It was about a year ago I started and completed the DP videos, but was disappointed to see no more , and randomly today this video pops up on my feed, very happy to see you again hopefully you will complete the rest of the patterns too 😊. I tried connecting you on LinkedIn too but it was restricted I think 😅.
Love to see you again, I look forward to rewatching as much of your videos as possible !
The man, the legend, welcome back
Previously, thank you for the knowledge, and welcome back.
What I get from the explanation is:
We should/must prefer to be implicit about a specific type of data that has the same structure and behavior, instead of being explicit (where we define it based on the actual concept or domain) about that type (CMIW).
Best notification from UA-cam in ages. I hope you've got more for us. 100% my favourite videos covering software development!
WHOA! i started watching your pattern videos like a week ago, binging them while at the gym, while taking walks, etc. i was like "eh it's been a long time since hes posted...he was a good teacher" and then here you are!!
I don't have words to describe how happy I am to see you back.. Love your style of teaching
Welcome back Christopher. Good to see you back 😊 Keep up the good work and make learning fun and easy. All power and good wishes ❤
The king of Design patterns is back🔥
Whoa, seeing you in my sub box is not something i expected today. Long time viewer of the channel, since the ramda days! Good to see you back.
Your channel helped me get into functional programming, and now i'm absolutely obsessed. Do you have any plans for more FP related videos?
Its always better to create a video for a problem than to create one for a video. Thank you for this video, polymorphism is used very frequently without much thought given 😢
Very interesting. Thank you very much for formulating that. I will try to keep it in mind moving forward. 🙏
Good video. I retired from software development years ago. I wrote some fairly complex systems and I used polymorphism at times. Much of it had to do with the implementation of corporate business rules. An example was doing 'credit checks' of customers. The calling system simply wanted a 'yes/no' credit check. However, HOW the credit check was executed was different depending on the kind of customer being checked. There were many different kinds of customers with different histories. The company had different rules and methods for each. Some required a simple database lookup while others required remote access to third-party systems. Using polymorphism the different rules could be independently developed and "bolted on" to the system. So as per your terminology this was very much different behavior.
- Welcome back! I was waiting for you.
- After all this time?
- Always
I used your design pattern videos to pass my cs class last term and here you are again lol
please continue have been rewatching your old stuff so glad to see this
Thanks bro for saying "differences in behaviour not data". It changed my approach towards polymorphism. Thanks again
I was literally googling for your name yesterday to know what are you up to these days and suddenly your new video pops up after 3 years. Thank you for sharing knowledge with us. You’re an amazing teacher!
This video may offer the best explanation I've seen for why subtyping via inheritance is problematic. Thanks!
I was trying to quit watching UA-cam but now I know it's not gonna happen. I am so happy you are back 😅
Once you separate models from behaviour classes (highly recommended) this issue is then about model abstractions. Model abstraction can be handled with composition rather than inheritance. Behaviour abstractions occur everywhere of course, you have many things that can do the same job. The question then becomes, does a model abstraction add any value to my behaviours? Model composition is still fragile, model interfaces will be more stable. If your code operates on disparate models you need it or mappers (a behaviour form of an interface!). If I define a feature for my app I can expose the interface that I expect to make my component completely self contained. If I write templates or generics it's normal to have a requirement of your that is an interface. The design consideration is a good one, it highlight lots of bad designs, but you haven't come full circle yet!
The idea that composition is better than inheritance must come from those with minds to small to comprehend inheritance.
@@djyotta you must be proud of such a high IQ comment, why not stay on topic and explain your opinion? Maybe there's not an intelligent one in there?
Holy shit. You're back. And the beard is ever so magnificent. Don't you dare disappear for such a long time again.
Wow man, so glad to see u again, you are an amazing teacher, please keep the quality content😊
I did not expect to see this in 2024, but I'm glad to see you're back. 😁
omg great to see u again! Ur videos has helped me tremendously during my time at chalmers, and im actually now TEACHING the same course i used ur videos to pass years before! Will recommend ur channel to all my students!
Thank you 🙏😊 And congratulations
Please don't disappear now my comment is to let you know you are gem, and the contents you present are just amazing. Many love ❤️❤❤. Please continue
Kul att se att du är tillbaka igen! Dina förklaringar av designmönster hjälpte mig enormt under skoltiden. 👍
Man önskade att fler lärare var såhär pedagogiska.
Tack så mycket!
I am determined to watch this video as many times as it takes to understand what he is talking about. 10 times later, maybe I should watch a refresher on polymorphism.
Welcome baaaaack!!!!!!!!! Happy to see you around after so much time! Hope you'll stay for a while, your content and way of explaining things are precious.
I didn't realise you hadn't posted for three years! I've been taking a break from coding but had to watch this video! Please keep posting!
He's alive!!! Glad to have you back!
my man still alive, good to see you again
IDK how this guy got into my recommendations, but, I loved this channel!
Thanks for sharing your valuable knowledge again. Your videos about design patterns helped me a lot when I landed my first job as a software developer. I hope 🤞 you don’t give a break anymore 😊
Glad that see you again, hope I can see another series also before I die. But high quality takes times, I'm really enjoying when watching your videos.
Welcome back, I have missed your content, it is great. Your analysis has been vital to my programming evolution, if only I'd have had teachers with your energy.
First time I've seen the use case for polymorphism clearly delineated. Great job. Very useful.
Your teaching is simpler and also in depth, good to see you back on youtube. Please create more good quality content !!
It all depends if you need to lift data to the type level. If Thunderbolt and Scratch are "dummy data" or "metadata" (basically hold no meaning) for your application, then sure, represent them through the Attack class. If your application does or will variate its behavior based on one or the other, expressing them as types might be advantageous. But I can still see teams deciding to go with conditionals and not introducing explicit types (if, e.g., the types introduced are not actually stable in the long term).
Another point is that if you can treat moves as data then you can also easily load them in (possibly even hot-load them in), so changing a move's behavior during development, balancing, testing, etc, can be as easy as changing a value in, say, a json file, which is just so convenient.
This is one of the most engaging software videos I've ever seen
Awesome points on polymorphism. Never thought that. Thanks. Really helpful.
you did really well with this video, i was able to flip into it and out of it, while just listening and you never lost me. i now know what you put into this video and thats always nice!
We miss your valuable teach.
Glad UA-cam was smart enough to recommend your video. Glad to see you posting. Always top notch stuff.
I really missed you. Welcome back Christopher
Glad to see you're back uploading videos! Your series on design patterns were instrumental in taking another step in my career!
I don't believe to be here in 48 minutes from publication. Been thinking about you lately
Yes, I completely agree that you should use polymorphism when dealing with varying behaviors. However, if you need variations in data and want to limit the number of such variants, you can employ the factory method pattern.
For instance, you can create a class called Attack with a private constructor. Then, add two static methods-thunderbolt and scratch-to control the initialization and ensure that no incorrect variants are created.
Welcome Back, Great to see you after 3 years :D
got randomly recommended this by the youtube algorithm, thought it was going to be about types because of the title (as in, type theory), but it seems to be about some object oriented language (not even clear which one), but was interesting to watch!
Legend is backkk!!! Good to see you, your system design videos are epic!! MASSIVE THANKS
Man, I was so happy to see your face in my feed again. Glad to have you back, your videos always helped me understand these concepts so much better.
Where were u man. I recently found(1.5 weeks ago) ur channel and always thought wht happened to this guy becoz u r such a good teacher .Last video ws 3 yrs ago. I then started studying design patterns using ur videos. I completed 15 of it going to complete it by tomorrow and u came back. I think u were waiting for me to complete 15 videos😂
I missed your videos, thanks for coming back!
it's been a very long time, nice to see again man!!
Welcome back! Your videos helped me a ton while getting my degree - good to see you're still at it!
happy to see you are back! keep the content coming! learning a lot.|
love the whiteboard, the editing and the why you teach :)
Good to see you after 3 years. I love the way you teach.
OMG what a surprise having you back! I still paying my bills thanks to you man ❣
Welcome back! Please upload more videos on system design and LLD. We appreciate your effort!
Oh hey look who's back! Thanks for the video! Ur gof patterns videos helped me a ton a few years back
Where the hell have you been all this time, we missed you.
I've really missed these talks. Welcome back!
Finally! Didn't expect that. 3 years of silence
This is the first video I watch from you. It makes complete sense, no idea why I never though of it like this. Looking forward to more videos!!
I'm very happy to hear. Welcome 😊
Welcome back, sir. Happy to know you are still creating content.
Hey @Chris, it's great to see you after such a long time! I've always been a fan of the way you present content with crisp editing.
I think a major complexity concern with the "wrong" use of polymorphism is the possibility of type explosion.
If there's a small number of implementations, I don't think it's such a big issue to use subtyping even when you only have variation in data.
Granted, it's more complex than it needs to be, like you mention. But this is complexity in terms of code. Conceptually, it feels more straight-forward to me to have a "Thunderbolt" type and a "Scratch" type rather than just a generic "IAttack" that you need to configure at instantiation. Giving things names helps organize the program, and few names are more powerful than types in this regard.
The parameterized class approach is more flexible too, I agree, but I think there is almost always a cost associated with flexibility. In this case, I think it introduces some additional cognitive load, because you are in some sense working at a lower level of abstraction (even though IAttack is more abstract than Thunderbolt, you need to contend with the implementation detail of the attack value when instantiating a "Thunderbolt" in this case; using polymorphism instead neatly encapsulates this).
If we don't use polymorphism here, it feels like some kind of factory (method?) would be in order instead. Something to somehow reify these concepts of "Thunderbolt" and "Scratch".
This also brings up the debate of: should you always go with the simplest possible solution that solves the problem as it is currently understood?. Or should you plan for some amount of future change? What amount and what kinds of change are we justified to plan for? Because one could reasonably predict your middle example evolving in the direction of the last example.
I've worked with code that has the opposite problem of type explosion. In this case, instead of defining an interface for, say, a drawing object with a draw() method, then subclassing the drawing object class with classes for doing lines, text, rectangles, and 50 other drawing operations, the designers used one class that had all the data required to draw anything, with 53 different constructors that take a type parameter and the type specific data, with a single draw function that used a switch statement to decide what actual drawing code to use. Totally miss the point of OOP much? It was the textbook definition of a C programmer who uses a C++ compiler and calls himself a C++ expert.
The worst part was that he was teaching the junior guys how to write good code. Not long after I was asked to make this monstrosity work, I left the company.
@@alamaralaaThat sounds painful for sure, and worse than type explosion.
What was the saying? "The 2 hardest problems in programming are naming things and off-by-one errors"? The "naming things" part to me encapsulates more than just picking the names of your components, it also implies deciding which components you should have. And that's the really hard part. Picking the right abstractions.
One might say this guy didn't abstract at all, but I don't think that's right. You can't _really_ solve a problem of significant complexity without at least some sort of abstraction. He just ended up choosing all the wrong ones. Definitely sucks for anyone who has to work with them, but I empathize with struggling to abstract well.
Thank you Christopher for your design pattern series. That is one of the reason I got promoted 🙏🙏🙏
Congratulations! 🎊😊
I did not expect you coming back, loved your design patterns, glad to see you're doing well!
Love to see you back, hope all good at your end. You have unique way of communicating complex things, Keep making video.