Sign in to follow this  
Tradone

General Question on Inheritance

Recommended Posts

Tradone    100
I have read everywhere that in oop inheritance is involved, but I'm sure that not all oop must use the qualities of inheritance. I've seen that the best anology of inheritance were the mammal taxonomies, and I can clearly see the point, but translating this anology back to real-life objects how are they related? If you can list me some STL classes that use inheritance, or some other classes that uses inheritance, I think I will have a clearer understanding of oop. Thank you very much for reading, any replies will be appreciated.

Share this post


Link to post
Share on other sites
dave    2187
Hey bud,

The taxonomy thing doesn't really relate to real life, moreover that real life was the most useful way of showing inheritance.

If you want an example of how inheritance works in a real world example then check this:

Supposing i want to write a set of entity managers in a rendering engine, like a mesh manager and a texture manager and so forth, well although those managers won't necessarily be identical, but they will share alot of common implementation. For example, they will both have a similar interface for adding and removing things from the manager. Their differences may only be so much as the way the entity is loaded from file, given a path.

The texture manager might use D3DXCreateTextureFromFile() whereas the mesh manager would use something like D3DXLoadMeshFromX(). As you can see the code of the shared implementation would have to be written twice.

Inheritance is a fairly good way of having this shared implementation written only once, in that you can put it in a class called something like BaseManager() and have the other managers derrive from it. The BaseManager class provides the implementation for the adding and removal of entities and might also have a pure virtual function that must be written in the derrived class. That way the derrived class just writes how it is loaded.

Now the relationship between the base class and the derrived classes are that a texture manager or mesh manager are a kind of BaseManager. This is because you can store them in something called a Polymorphic Collection (google for that,it is a very important concept). This is where you can have a collection of BaseManager pointers and can store the addresses of any of the derrived classes in it. This means that you could have collection of all your managers, even though they are actually different types.

I warn that this is not the most suitable way of solving this problem because you may not need the derrived managers to be a kind of the base manager. If you want to solve this properly i suggest looking into containment and private inheritance.

I would also like to warn that as it seems you are new to this language and OO design, don't fall into the trap of overusing inheritance. It seems powerful at first, and it is, but it can be misused and lead to awful code and design.

Hope that helps mate,

Dave

Share this post


Link to post
Share on other sites
Tradone    100
Quote:
Original post by Dave
Hey bud,

The taxonomy thing doesn't really relate to real life, moreover that real life was the most useful way of showing inheritance.

If you want an example of how inheritance works in a real world example then check this:

Supposing i want to write a set of entity managers in a rendering engine, like a mesh manager and a texture manager and so forth, well although those managers won't necessarily be identical, but they will share alot of common implementation. For example, they will both have a similar interface for adding and removing things from the manager. Their differences may only be so much as the way the entity is loaded from file, given a path.

The texture manager might use D3DXCreateTextureFromFile() whereas the mesh manager would use something like D3DXLoadMeshFromX(). As you can see the code of the shared implementation would have to be written twice.

Inheritance is a fairly good way of having this shared implementation written only once, in that you can put it in a class called something like BaseManager() and have the other managers derrive from it. The BaseManager class provides the implementation for the adding and removal of entities and might also have a pure virtual function that must be written in the derrived class. That way the derrived class just writes how it is loaded.

Now the relationship between the base class and the derrived classes are that a texture manager or mesh manager are a kind of BaseManager. This is because you can store them in something called a Polymorphic Collection (google for that,it is a very important concept). This is where you can have a collection of BaseManager pointers and can store the addresses of any of the derrived classes in it. This means that you could have collection of all your managers, even though they are actually different types.

I warn that this is not the most suitable way of solving this problem because you may not need the derrived managers to be a kind of the base manager. If you want to solve this properly i suggest looking into containment and private inheritance.

I would also like to warn that as it seems you are new to this language and OO design, don't fall into the trap of overusing inheritance. It seems powerful at first, and it is, but it can be misused and lead to awful code and design.

Hope that helps mate,

Dave


Thanks that was a really handy advice.
Yea, because my objects interact with other objects but there is no use of inheritance, and since many tutorials that I've read strongly reinforces inheritance, I was starting to accusing that my code is perhaps not oop.
So I was examining the string class, and some STL classes and it seems like they don't use that much inheritance ( actually I don't think I spotted any! )

So I think I'm going on the right track.
I divided my application into several classes
Container Classes ( you see all container classes here are map types, maybe I can incorporate inheritance here, b/c all container classes are constants once they're set, besides the environmental variable class that can be set by the user whenever he adds a command )
---------------------
Data class
parameter class
environmentalvariable class
path class

ContainerHelperClasses
----------------------
if class ( i over loaded the ++ and -- operators to add a level of if )
loop class ( same to this, using levels of loops made it possible for short recursive programming )

Output Classes
-----------------------
Cookie Class
GeneralPrint class

Algorith Classes
-----------------------
Manipulation Class ( which translates strings to int's and int's to string etc.)

and currently adding more classes to the structure, but does this sound right? I have like 10 cpp files already, and I don't want this to go bad. ( first time programming in oop, just coming out the procedural closet )

Share this post


Link to post
Share on other sites
dave    2187
Hey bud,

Ok well for me to be able to truely tell you what i think i need a brief description on how you are going to use those objects. For example, im not entirely sure why you want an ifstatement class. This seems inplausable to me.

The concept of OO is that you are encapsulating alike functionality. You dont have to go as completely OO as Java does. I think you have roughly the correct idea with the output classes though, i think you should be looking to implement a base class and then derrived classes that redirect the output to certain places. remember what i was saying about common code.

So if you can refresh me on what your intentions are then i will gladly post some more feedback.

Dave

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this