koobas.hobune.stream
Why use inheritance?
Hello,
In my game I created class Item which contains all data what I needed (base info, stats, damage, defense etc.). When some fields is not needed (example defense for weapon) I simply put there null.
Yesterday I was watching cool inventory tutorial and I found that author splitted mine Item class into 4 classes (Item -> Equipment,Weapon,Consumable). Now question.
Why that inheritance is better? Its more efficient than nulling not needed fields and have everything in one big class? Or its only for cosmetic purpose? I know what inheritance is, but I had never used it before, now I am creating something bigger and I am just wondering what approach is better and WHY. I searched on google but I found only how it is and how to use it but not answer why its better other than cosmetic.
I know its silly question but "Better to ask the way than go astray."
Him splitting it into 4 classes ins$$anonymous$$d does not say much. What kind of information did he want to retrieve from each class separately?
To me, this has to do with the approach one follows. For example, you could have a tag on the item's game object that deter$$anonymous$$es its class (e.g. consumable, weapon, etc.) and run the appropriate class by name. Otherwise, you might be retrieving irrelevant or null data (because even developers forget what they do in (not necessarily) huge projects). It's a matter of organizing stuff and how you stick to them. Performance-wise, it sounds like his method would be better.
Also, don't forget, people in tutorials or assets on the AssetStore tend to make exaggerated configurability with their code, which is sometimes unnecessary.
He split it into 4 classes I mean:
Base Class - Item (Item name, description, sprite, cost, ID)
Equipment(inherit from Item, add: float defense, str, agi, sta$$anonymous$$a)
Weapon(inherit from Item & Equipment, add: float damage, speed)
Consumable(inherit from Item, add: float manaToAdd, healthToAdd)
In my project I have everything inside one class Item and I am nulling not needed fields.
Hmm, I guess it's easier to visually see in what's going on in your head. If you're nulling everything and like you said it's a HUGE amount items, eventually you'll confuse yourself with a lot of variable names and all. So, better organization.
Implementing a huge class with fields that are unnecessary is inefficient and conceptually confusing. For instance, if a weapon can't add defense but each time you equip a weapon you are adding 0 defense then you are perfor$$anonymous$$g an unnecessary call and storing unnecessary data. Also, since every item has a defense value it will be assumed by programmers (including yourself) that this value is useful for all items so exa$$anonymous$$ing your code will be harder to understand.
However inheritance is a feature and can be abused. If you are learning about it then I would encourage you to also learn about interfaces and composition in addition. That way you will use the correct feature for the situation. In general
inheritance: X is a Y
interface: X can do Y
composition: X has a Y
The situation you're describing as a potential competitor to inheritance ("home-brew" inheritance if you like) only works when you write your class for which you can foresee changes. Now imagine a class is coming in a DLL from a third party developer. Let's not go too abstract and say that class is ScriptableObject and the third party developer is UnityTechnologies. This class is used by millions of developers all over the world. Now imagine unity would literally include the entire vocabulary (and that only for single-worded variable names) of nulled variables inside of the ScriptableObject to satisfy each and every developer. So that instead of inheriting from scriptable object you'd find a variable of nearly any name already there. One instance of such class would trash your entire RAM. This is only one of the reason why using inheritance.
I can ask an opposite question: why not use inheritance?
Inheritance is an instrument to be used where appropriate.
Also in your particular case finding variables that are irrelevant to a specific case and also having null values is confusing to any developer other than you. Because in fact you have an inheritance, but the problem is it's an implicit inheritance in your head instead of "on paper". You yourself might return to it in a week and run a session of guess-work instead of code being self-explanatory.
Thank you for your comment, now I see why I should do that.
To me the question is why wouldn't you split them up in different classes. Why would you keep screws and nails in the same bucket in your garage. It takes minimal effort to put them into separate buckets when you bring them home from the hardware store (to set up the classes), and after that there's only benefits: Better type safety (you can't equip a Consumable XP boost as your weapon), code completion works better and finding variables is easier (you don't get accuracy and weight suggested as variables when you deal with XP boosts). More maintainable code (if you change something in Weapon class, you can be sure Consumables don't break), possible memory savings (might not be a big thing, but all variables you declare will reserve at least the memory to store the reference to whatever can be put into them. An unnecessary long[100] in each of your inventory items when it's really only needed in one is waste)...
Inheritance is just a way to make your code more manageable and maintainable and if done correctly, less prone to bugs. Might not make a difference if the classes are 20 lines long but it'll start to make a difference when you have hundreds of lines to go through.
This is really just a general computer programming question. You'll find many more explanations, that apply 100% to Unity, in general programming sites. Really. For every answer you read here, there's the same answer on a programming site, but with lots of comments which improved and explained it more; and answers next to it giving a different point of view.
Scripts are just computer programs. And inheritance is just a language feature, like functions, classes, enumerations ... . It's one of the trickier ones (look at a textbook -- Inheritance comes near the end.) I'd say to attempt to use inheritance if you have a month+ to waste (whenever you learn something new, the first few tries are junk) and you're really interested in being a better coder. And if you don't mind finally realizing that inheritance may totally not work with the exact thing you're doing now, but it was still good to learn.
