Computer Science Canada

Subclasses
Author:  SilverSprite [ Fri Jul 11, 2003 2:37 pm ]
Post subject:  Subclasses
hm.. how could i create a subclass called predators of a class called animals?
Author:  Catalyst [ Fri Jul 11, 2003 2:52 pm ]
Post subject: 
code:

class animal
{
   public:

   int x;

};

class predator:public animal
{
   public:

   int y;


};
Author:  SilverSprite [ Fri Jul 11, 2003 8:31 pm ]
Post subject: 
thx..
Author:  Tony [ Fri Jul 11, 2003 11:48 pm ]
Post subject: 
how would I call something like that then?

animal::predator::y ?
Author:  SilverSprite [ Sat Jul 12, 2003 1:08 am ]
Post subject: 
? no you just do it normally..
code:
predator.y

at least thast how it is in java.. sortof lool
Author:  Tony [ Sat Jul 12, 2003 1:37 am ]
Post subject: 
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?
Author:  UBC_Wiskatos [ Sat Jul 12, 2003 11:46 am ]
Post subject: 
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).
Author:  Tony [ Sat Jul 12, 2003 3:07 pm ]
Post subject: 
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() ?
Author:  SilverSprite [ Sat Jul 12, 2003 3:25 pm ]
Post subject: 
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..
Author:  Tony [ Sat Jul 12, 2003 3:32 pm ]
Post subject: 
awesome, thx guys Smile Not that I need this at the moment, but I learn more about programming from compsci.ca then from any teacher Laughing
Author:  UBC_Wiskatos [ Sat Jul 12, 2003 3:35 pm ]
Post subject: 
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 <i>inherit</i> 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?
Author:  Mazer [ Sat Jul 12, 2003 7:28 pm ]
Post subject: 
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()
Author:  UBC_Wiskatos [ Sat Jul 12, 2003 9:01 pm ]
Post subject: 
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.
Author:  rizzix [ Sat Jul 12, 2003 11:08 pm ]
Post subject: 
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)
Author:  Tony [ Sat Jul 12, 2003 11:21 pm ]
Post subject: 
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 Smile
Author:  PaddyLong [ Sun Jul 13, 2003 12:35 am ]
Post subject: 
hmm, I'll take a jab at trying to shed some light on inheritance...

let's take an example of the people in a school.... there will be classes for person, student, teacher and principal ... each instance of any of these classes is an object (this is the main premise of OOP)

ok so class person has data and methods (methods being functions/procedures...) that every person would have... name, age and sex for example and then methods (other than get/sets that need it - that's encapsulation... a whole other story Wink)

now each of student, teacher and principal will inherit person as well as have some unique data and methods
so the student class might have grade, timetable and marks data
and then a method learn (probably not in a computer program... but just to help the example Razz)

the teacher class would probably have timetable data, and possibly a set of class objects
and then a method teach

the principal class might not have any unique data, so the only data this class has would be the name, age and sex data that is inherited from person
then the principal might have a method punish or roamthehalls or what ever it is principals do


hopefully this clears it up for you if you weren't understanding the usefullness of inheritance
Author:  Catalyst [ Sun Jul 13, 2003 12:59 am ]
Post subject: 
one really useful facet of inheritance is polymorphism (along with abstraction)
with polymorphism methods in a base class can be overidden in subclasses but still be accessed through the base class pointer, allowing for great flexibility
Author:  Tony [ Sun Jul 13, 2003 1:03 am ]
Post subject: 
could someone write a tutorial about all the difference inheritance types or what not... those polymorphing and other things classes can do.
Author:  SilverSprite [ Sun Jul 13, 2003 1:23 am ]
Post subject: 
yeah i'd like for a simple tutorial for polymorphism and abstraction.. inheritance is simple enough..

:


You can syndicate this boards posts using the file backend.php or view the topic map using sitemap.php.

Terms of Use | Privacy Policy