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.
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 :)
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 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. 🥳🥳🎉🎉❤❤❤
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
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).
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!
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.
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!
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 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!
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.
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!
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.
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 😅.
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 😢
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 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.
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.
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!
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!
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 😊
That's precisely the problem I'm facing now. I created a model of hemodynamics in the Modelica language. I want to use this model to model different types of disorders - (left ventricular systolic failure, aortic stenosis, mitral insufficiency...) - everything is solved by setting the parameters of the model - that is, by setting different data values with which I change the behavior. So Hemodynamics
I understand the intent of this approach is to reduce unnecessary complexity, and I agree. However the provided examples don't support this. If I were making a battle game like in the example, I *would* want to define an abstract IAttack class and "Thunderbolt" and "Scratch" subclasses. Why? Because they are instances with constant values known at compile time. When the name, damage, etc are already known, subclassing provides self-documenting code. If we replaced inheritance with a single Attack class as suggested, I would have to instantiate an Attack with Thunderbolt's values numerous times in the project. While this video should have been a discussion about when to use abstract classes (e.g. IAttack) vs interfaces (IMove), it was still a good reminder to avoid unnecessary complexity. Keep the content coming!
Personally, I wouldn't get too hang up on the example. Like, I see no reason why you'd even implement different attacks or moves as classes in something like, say, a pokémon-like scenario. Think about it, you'll end up with thousands of entries to figure the hierarchies of, while a simple array of struct of move data would do the same job. It is also just as self-documenting and could easily be extended to be readable from, say, a json file or formatted plain-text or whatever, so you even get a lot of convenience during development plus an easy path for modding, all for free : ) Sure, you might end up with a switch in some "move solver" class/function/method somewhere, but that's a single switch in exchange for god knows how many classes and sub-classes and instantiation to hop around. Writing the logic for this switch would also not be any harder than figuring out your class hierarchy, or less readable, available or "self-documenting" for that matter. This approach also means that you have all move data in one single place and all logic to decide how a given move should be handled at another single place - figuring out patterns or if some kinds of moves are disjointed in their data or classifications (which could easily be extended from the logic into the data) would be much simpler, with no hopping necessary. The main idea of the video though - don't use polymorphism for simple member value differences - definitely stands, imo.
@@user-sl6gn1ss8p Interesting take. For context, I code in Kotlin so it's not an issue to have multiple classes defined in a single file. The suggestion of an array that contains all the possible attacks in this example battle system, and then a dedicated class to access the array in a logical way, is unusual to me. At that point I'd just implement a database and a DAO that's responsible for returning the appropriate object (e.g. an Attack instance). When we bring a database into the picture, I agree there's absolutely no need for polymorphism.
"When we bring a database into the picture, I agree there's absolutely no need for polymorphism" I don't really know kotlin, but I think that was kind of the main point : p I tried to keep the example as "agnostic" as possible. Also, I was talking of a pokémon-like scenario: so a limited number predefined moves and a turn based system which deals with one move at a time. The idea is that you simply define the data of each move in one place and have some conditional logic to decide how to handle the data (basically a dispatcher). The data can come from a database, the initialization list of an array of c-like structs, a text file, json, w/e. The "move solver" I mentioned would not be so much responsible for accessing the array, but for routing the data to the appropriated method, function or w/e which actually deals with the move, depending either on introspection on its data or a simple "moveType" field. It doesn't even need to be a class (say, if you are using C for some reason), but it certainly can be. For something pokémon-like the dispatching would only have to deal with special effects. The main draw, to me, is that you offload the complexity as far away as possible to the definition of the moves themselves, which are probably the thing you will be fiddling with the most during development - they become just plain old data, represented however you prefer. Also, all the complexity in the conditional "dispatch" logic, to the extent it is is even necessary, is really just encoding the same information as a flat class hierarchy would, but, in my opinion, more explicitly. I do get that some languages, frameworks or tools may have their own ways to achieve the same thing, though. Hope that makes sense, and sorry if I've written a little too much : p
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.
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!
Functions are data, so you can save a function in your Move class to apply it to Health (v => v - x or v => 100) and another function to apply to Armor (v => v or v => 100). What about having more data fields in the subtypes? Like implementing disjoint unions. Is that a behavioural variation?
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.
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?
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.
Great to see you back!.. Chances are I’ve not understood, but in your second example, if you add a numeric value for damage as an argument for your concrete classes, then if you want to change the damage amount you’ve got to do that throughout your codebase?.. Whereas if you’d stuck with your polymorphic approach you’d just change a single class. Alternatively you could have an applyDamage method with a switch statement based on the type of attack, but I guess this would contravene the O in the SOLID principles.
I use to watch you videos and found them entertaining. Then you seem to have disappeared. I'm glad to see you back! I hope you'll stick around a while....
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 :)
I've never been more engaged with software engineering TH-cam content. Your presentation skills are excellent.
Welcome back! Got a huge amount of value out of this channel in my early days of becoming a dev
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.
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!
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.
Your teaching is the greatest and simpler....❤
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 😊
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. 🥳🥳🎉🎉❤❤❤
Word to mother....ur design patterns videos helped me nail an interview in 2017 🤣🤣🤣. Now I'm a Lead software engineer. Thanks
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
I watch your videos and you are the first teacher whoes course i can buy without thinking about money.
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).
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 😊😊
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.
The man, the legend, welcome back
The king of Design patterns is 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?
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!
Thanks for your work, I got a masters in software engineering 2 years ago and your videos on the design patterns really helped me.
I don't have words to describe how happy I am to see you back.. Love your style of teaching
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!
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.
Happy to see you upload after 3 years love the way you teach..
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!
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.
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 😅.
Great to see you again Christopher. Miss your videos of design patterns and discussions about principles. Welcome Back!!
So happy to see you back. You're the sole educator whose TH-cam videos I choose to view at regular speed, even when they extend to an hour.
This video may offer the best explanation I've seen for why subtyping via inheritance is problematic. Thanks!
Thanks bro for saying "differences in behaviour not data". It changed my approach towards polymorphism. Thanks again
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
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. 🙏
Awesome to see you back Chris! I’ve learned a lot from your videos, and have always enjoyed hearing your perspective on things. 😎👍
I was trying to quit watching TH-cam but now I know it's not gonna happen. I am so happy you are back 😅
He's alive!!! Glad to have you back!
Love to see you again, I look forward to rewatching as much of your videos as possible !
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!!
This is one of the most engaging software videos I've ever seen
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.
I did not expect to see this in 2024, but I'm glad to see you're back. 😁
- Welcome back! I was waiting for you.
- After all this time?
- Always
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!
my man still alive, good to see you again
IDK how this guy got into my recommendations, but, I loved this channel!
Best notification from TH-cam in ages. I hope you've got more for us. 100% my favourite videos covering software development!
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 !!
please continue have been rewatching your old stuff so glad to see this
I used your design pattern videos to pass my cs class last term and here you are again lol
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!
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
Good to see you after 3 years. I love the way you teach.
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!
We miss your valuable teach.
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 TH-cam was smart enough to recommend your video. Glad to see you posting. Always top notch stuff.
That's precisely the problem I'm facing now.
I created a model of hemodynamics in the Modelica language. I want to use this model to model different types of disorders - (left ventricular systolic failure, aortic stenosis, mitral insufficiency...) - everything is solved by setting the parameters of the model - that is, by setting different data values with which I change the behavior. So Hemodynamics
I know way too little about that domain to provide any insightful response 😅 But I’m very happy to hear that the content is relatable 😊😊
Welcome back Christopher. Good to see you back 😊 Keep up the good work and make learning fun and easy. All power and good wishes ❤
I understand the intent of this approach is to reduce unnecessary complexity, and I agree. However the provided examples don't support this. If I were making a battle game like in the example, I *would* want to define an abstract IAttack class and "Thunderbolt" and "Scratch" subclasses.
Why? Because they are instances with constant values known at compile time. When the name, damage, etc are already known, subclassing provides self-documenting code.
If we replaced inheritance with a single Attack class as suggested, I would have to instantiate an Attack with Thunderbolt's values numerous times in the project.
While this video should have been a discussion about when to use abstract classes (e.g. IAttack) vs interfaces (IMove), it was still a good reminder to avoid unnecessary complexity. Keep the content coming!
Personally, I wouldn't get too hang up on the example.
Like, I see no reason why you'd even implement different attacks or moves as classes in something like, say, a pokémon-like scenario. Think about it, you'll end up with thousands of entries to figure the hierarchies of, while a simple array of struct of move data would do the same job. It is also just as self-documenting and could easily be extended to be readable from, say, a json file or formatted plain-text or whatever, so you even get a lot of convenience during development plus an easy path for modding, all for free : )
Sure, you might end up with a switch in some "move solver" class/function/method somewhere, but that's a single switch in exchange for god knows how many classes and sub-classes and instantiation to hop around. Writing the logic for this switch would also not be any harder than figuring out your class hierarchy, or less readable, available or "self-documenting" for that matter.
This approach also means that you have all move data in one single place and all logic to decide how a given move should be handled at another single place - figuring out patterns or if some kinds of moves are disjointed in their data or classifications (which could easily be extended from the logic into the data) would be much simpler, with no hopping necessary.
The main idea of the video though - don't use polymorphism for simple member value differences - definitely stands, imo.
@@user-sl6gn1ss8p Interesting take.
For context, I code in Kotlin so it's not an issue to have multiple classes defined in a single file.
The suggestion of an array that contains all the possible attacks in this example battle system, and then a dedicated class to access the array in a logical way, is unusual to me.
At that point I'd just implement a database and a DAO that's responsible for returning the appropriate object (e.g. an Attack instance).
When we bring a database into the picture, I agree there's absolutely no need for polymorphism.
"When we bring a database into the picture, I agree there's absolutely no need for polymorphism"
I don't really know kotlin, but I think that was kind of the main point : p
I tried to keep the example as "agnostic" as possible. Also, I was talking of a pokémon-like scenario: so a limited number predefined moves and a turn based system which deals with one move at a time.
The idea is that you simply define the data of each move in one place and have some conditional logic to decide how to handle the data (basically a dispatcher). The data can come from a database, the initialization list of an array of c-like structs, a text file, json, w/e.
The "move solver" I mentioned would not be so much responsible for accessing the array, but for routing the data to the appropriated method, function or w/e which actually deals with the move, depending either on introspection on its data or a simple "moveType" field. It doesn't even need to be a class (say, if you are using C for some reason), but it certainly can be. For something pokémon-like the dispatching would only have to deal with special effects.
The main draw, to me, is that you offload the complexity as far away as possible to the definition of the moves themselves, which are probably the thing you will be fiddling with the most during development - they become just plain old data, represented however you prefer.
Also, all the complexity in the conditional "dispatch" logic, to the extent it is is even necessary, is really just encoding the same information as a flat class hierarchy would, but, in my opinion, more explicitly.
I do get that some languages, frameworks or tools may have their own ways to achieve the same thing, though.
Hope that makes sense, and sorry if I've written a little too much : p
Wow man, so glad to see u again, you are an amazing teacher, please keep the quality content😊
Welcome back! Your videos helped me a ton while getting my degree - good to see you're still at it!
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.
Glad to see you're back uploading videos! Your series on design patterns were instrumental in taking another step in my career!
Welcome back! Please upload more videos on system design and LLD. We appreciate your effort!
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.
I've really missed these talks. Welcome back!
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!
I really missed you. Welcome back Christopher
Functions are data, so you can save a function in your Move class to apply it to Health (v => v - x or v => 100) and another function to apply to Armor (v => v or v => 100).
What about having more data fields in the subtypes? Like implementing disjoint unions. Is that a behavioural variation?
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.
OMG what a surprise having you back! I still paying my bills thanks to you man ❣
Welcome back, sir. Happy to know you are still creating content.
The +/= example is brilliant. It's like the Liskov substitution principle and "The Square Hole".
Awesome points on polymorphism. Never thought that. Thanks. Really helpful.
Welcome Back, Great to see you after 3 years :D
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.
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?
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 missed your videos, thanks for coming back!
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 😊
good advice. The key to write complex code is to keep striving for (relative) "simplicity". :-)
I am in love with this guy !!! He radiaties positivity and passion :) Glad to see u again Christopher:)
Thank you Christopher for your design pattern series. That is one of the reason I got promoted 🙏🙏🙏
Congratulations! 🎊😊
Great to see you back!.. Chances are I’ve not understood, but in your second example, if you add a numeric value for damage as an argument for your concrete classes, then if you want to change the damage amount you’ve got to do that throughout your codebase?.. Whereas if you’d stuck with your polymorphic approach you’d just change a single class. Alternatively you could have an applyDamage method with a switch statement based on the type of attack, but I guess this would contravene the O in the SOLID principles.
I use to watch you videos and found them entertaining. Then you seem to have disappeared. I'm glad to see you back! I hope you'll stick around a while....
Loved this video. Thank you so much for the bite-size CS training. Love your style, heart, and expertise.
it's been a very long time, nice to see again man!!
Oh hey look who's back! Thanks for the video! Ur gof patterns videos helped me a ton a few years back
Legend is backkk!!! Good to see you, your system design videos are epic!! MASSIVE THANKS
Oh my goodness, the man the myth the legend, finally returns!!