Subclasses

[SilverSprite]

hm.. how could i create a subclass called predators of a class called animals?

[Catalyst]

code:

class animal {    public:    int x; }; class predator:public animal {    public:    int y; };

[SilverSprite]

thx..

[Tony]

how would I call something like that then?

animal::predator::y ?

[SilverSprite]

? no you just do it normally..

code:

predator.y

at least thast how it is in java.. sortof lool

[Tony]

then if you still get to use it as a class, whats the point of declearing it as a "subclass"... does it make anything different?

[UBC_Wiskatos]

tony wrote:

then if you still get to use it as a class, whats the point of declearing it as a "subclass"... does it make anything different?

The class Predator is a class derived from the class Animal, and inherits its methods and whatnot. This is one of the things with OOP, inheritance. So if the class animal had basic animal behaviour like Run() and Eat(), and the class Predator inherited it, Run() and Eat() would automatically be in the class Predator, and you wouldn't have to recode them. As well, you could access the class Predator through the class Animal because the pattern of the functions are the same, but that's a bit more complicated (that is, pointer to Animal could access Predator's Animal functions no problem).

[Tony]

so then would it be something like:

code:

class animal {    public:    void run()    {} }; class predator:public animal {    public:    void EatMeet()    {} }; class hervavor:public animal {    public:    void EatGrass()    {} };

?

And I would be able to access
predator.run()
and hervavor.EatGrass() ?

[SilverSprite]

yep thast right! so predator and herbivore each get to use all the functions and whatnot inside animal (mind you the converse isnt true) as well as the functions inside themselves..

[Tony]

awesome, thx guys Not that I need this at the moment, but I learn more about programming from compsci.ca then from any teacher

[UBC_Wiskatos]

tony wrote:

so then would it be something like:

code:

class animal {    public:    void run()    {} }; class predator:public animal {    public:    void EatMeet()    {} }; class hervavor:public animal {    public:    void EatGrass()    {} };

?

And I would be able to access
predator.run()
and hervavor.EatGrass() ?

Correct. Perhaps, a good example of real-world usage of this is in a simpler game engine (by that I mean non-COM because then it becomes a bit more complicated). Say you had a function called Render() in version 1.0... Well, you came out with version 2.0 and it now has a function RenderCoolness() that everyone is supposed to use. If people use the old Render() that function doesn't exist. However, if you were to inherit your old engine 1.0 to the new 2.0, people could still access Render(), and it wouldn't break their older games. Do you see what I mean?

[Mazer]

i understand the concept but not the practicality in your example. if everybody is supposed to use RenderCoolness() then why not dump the old Render() completely and name the new one Render()

[UBC_Wiskatos]

Mazer wrote:

i understand the concept but not the practicality in your example. if everybody is supposed to use RenderCoolness() then why not dump the old Render() completely and name the new one Render()

If the new Render takes different parameters and whatnot, old games based on that old function will be broken, because they'll call Render() and this one is very different. This is important if you have a large graphics DLL you made, and several games are installed on your computer that use it. If you want to upgrade the version, all the games will be affected, some newer games will know to use the new function, but older games may not. This is the way DirectX works. Even the DirectX 3.0 functions are present, so that old games can still run.

[rizzix]

that could be one reason to use inheritance.. but usually its for a proper oop implementation...

While explaining classes, i mentioned that this concept is not easy to explain. It relies on three other important points. (the four concepts are interrelated. u break one u broke the rest!)

maybe when i come out with a Java Tutorial, it might shed some light on this philosophy. (if i do a good job that is)

[Tony]

rizzix wrote:

maybe when i come out with a Java Tutorial, it might shed some light on this philosophy. (if i do a good job that is)

plz do