🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
C# Workshop - Week 6 (Ch. 18 - 19)
Quote:
For example, IS-A Car a type of Vehicle? IS-A Mage a type of CharacterClass? IS-A Weapon a type of item. Whenever you can answer "yes" to the IS-A question, it's a good indication you may have the possibility of inheritance. On other hand, it's important to remember that just because something IS-A type of something else, doesn’t mean inheritance is required. Often times creating an instance of a class and giving it a field called "Type" or something similar is enough.
[Opinion][WARNING]
And in my experience, all of the above examples probably fall into the above caveat. The type of an object isn't readily/cleanly available at runtime, so placing information there ("this vehicle is a car", "this character is a Mage", "this item is a Weapon") is problematic. These are properties (hint, hint) of the vehicle/character/item.
Inheritance is best used when you don't care what the derived class is. For example, output classes. It is useful to have a common base class for output to a file and output to the screen so that your code can use either; not particularly caring where the data ends up. If your code cares what derived class a particular object is, this is a good indicator that your design is flawed, and inheritance might not be the way to go.
[/Opinion][/WARNING]
Quote: Original post by TelastynWhy is it problematic?
[Opinion][WARNING]
And in my experience, all of the above examples probably fall into the above caveat. The type of an object isn't readily/cleanly available at runtime, so placing information there ("this vehicle is a car", "this character is a Mage", "this item is a Weapon") is problematic.
Much of the time, you never need to know what the actual type of an object is; you only need to know what you can do with it, which is where things like interfaces and inheritance trees are really at home. You don't care whether the object the player is trying to use is an IonCannon or a LaserTurret; all you care about is whether it can be Fired(). By keeping all of your code on a 'need to know' basis, you reduce the number of factors that can affect a section of code, and thus the chance of breaking it when changing something.
Also, some information about the runtime type of an object is readily available - specifically, testing whether an object is an instance of a particular type or of a type derived from that type is very simple using keywords like 'as':
void onPressFireButton(){ IFireable obj = getObjectThePlayerIsStandingNextTo() as IFireable; if(obj != null) { obj.Fire(); }}
Quote:
Much of the time, you never need to know what the actual type of an object is; you only need to know what you can do with it, which is where things like interfaces and inheritance trees are really at home.
For you or I perhaps, but for people who are not terribly experienced with program design, following the simple "IS-A" guideline will create scenarios where they need to know what type the object is.
Quote:
You don't care whether the object the player is trying to use is an IonCannon or a LaserTurret; all you care about is whether it can be Fired(). By keeping all of your code on a 'need to know' basis, you reduce the number of factors that can affect a section of code, and thus the chance of breaking it when changing something.
Absolutely.
Quote: Original post by superpig
Why is it problematic?
Let's look at the example of Mage extends CharacterClass... There are a variety of things that need to know what type of CharacterClass is being used. The name of the CharacterClass, things that have "Mage" as a prerequisite, perhaps some presentation things...
Sure, you could supply a virtual Name property and various prerequisite fields, but at that point what are you gaining from inheritance? You're not really changing behavior, and certainly not in any way that couldn't be done (better) via the strategy pattern.
Quote:
*snip* is/as
But as you've already said (much better than I), much of the time you don't/shouldn't care what type of derived object an instance is. Is/as and reflection are there for the exceptions to 'much of the time'.
I was just trying to communicate the tendency for beginners to over-use inheritance to the detriment of that derived class apathy.
Quote: Let's look at the example of Mage extends CharacterClass... There are a variety of things that need to know what type of CharacterClass is being used. The name of the CharacterClass, things that have "Mage" as a prerequisite, perhaps some presentation things...
There are no things that need to know what type of character class being used is...At least none that I can think of. Perhaps you can give some examples?
If things need to know about the class, then the interface or base class isn't engineered correctly.
Cheers!
Indeed. But what is the reasoning behind subclassing them rather than simple instantiation? Especially since the subclasses will be instantiated once at most?
I can't think of any property that isn't better handled as a property or any method which wouldn't be better served as a drop-in strategy since they are reused (like the dnd money and hp calculations). The various independent Class properties are only loosely tied because the rules say so (for now), not some intrinsic requirement of design.
Ah, wait... oh. Delegates aren't covered for another 3 weeks... How unfortunate. Well, that's reason enough I suppose to eschew strategy style designs.
I can't think of any property that isn't better handled as a property or any method which wouldn't be better served as a drop-in strategy since they are reused (like the dnd money and hp calculations). The various independent Class properties are only loosely tied because the rules say so (for now), not some intrinsic requirement of design.
Ah, wait... oh. Delegates aren't covered for another 3 weeks... How unfortunate. Well, that's reason enough I suppose to eschew strategy style designs.
For those who want to know more about how to decide whether a class should be inherited from another one, you'll find some very interesting (and general) articles about object oriented design on objectmentor.com.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement