I had to create an abstract base class and 6 derived classes for a CS homework, and I chose to make a graphics engine. Probably the most useful things that I noticed about using inheritance in this "game" was that I only had to define certain functions once (like my loadBitmap method), and polymorphism. I had a pure virtual function CImage::draw(HDC dest) const, which was defined in all the derived classes. I had a render function which would cycle through and STL list of CImage*s and call the draw method for each. This way I could keep all of my objects contained in a single list, but have each unique draw method called.

Using virtual functions (key to inheritance) will cost you a bit of speed (and some memory, I suppose) because of vtables and their associated indirection. However, in many cases, they more than make up for it by extensibility and ease of maintenance.

To Miserable - virtual functions aren''t an inheritance issue but a polymorphism issue. Object-based languages only provide inheritance. Object-oriented languages provide both.

To the OP - Object-oriented hierarchy design is a topic subject to much debate by software engineers. Many claim to have found THE answer (which is 42, as everyone knows), many books have been written. In most cases, the solutions are very ad-hoc, outside of well-known "hiearchy snippets" known as "design patterns" (e.g. see there).

Regarding your example, a mesh is not a polygon, it contains polygons - you would not derive your Mesh class from your Polygon class, you would give it a member variable. Your Polygon might provide a member function returning the polygon''s normal - which wouldn''t make any sense for a non-planar mesh. On the other hands, both could inherit from an abstract class defining a draw() member function, as YoshiN pointed out. That would let you treat both polymorphically as far as drawing is concerned.

Designing a class hierarchy is primarily about designing interfaces - implementation inheritance is a nice benefit, but not necessarily a design goal. A class with too narrow an interface is useless, a class with too wide an interface is unwieldy (a.k.a. ''bloated''). A class (or interface) should represent/do one single thing and represent/do it well.

<rant>I have seen too many classes with public get/set member functions for each and every member variables - including ones which are mere implementation details. That''s no more abstraction nor encapsulation than having the members themselve be public.</rant>


[ Start Here ! | How To Ask Smart Questions | Recommended C++ Books | C++ FAQ Lite | Function Ptrs | CppTips Archive ]
[ Header Files | File Format Docs | LNK2001 | C++ STL Doc | STLPort | Free C++ IDE | Boost C++ Lib | MSVC6 Lib Fixes ]

quote:Original post by Fruny
To Miserable - virtual functions aren''t an inheritance issue but a polymorphism issue. Object-based languages only provide inheritance. Object-oriented languages provide both.

... Don''t I feel stupid! You''re right as always; however, virtual functions are (of course) important in a situation such as the OP described, with inheritance-based polymorphism.

You''re right as always;

If I were, that would quickly become boring. Thankfully, I was proved wrong very recently

However, virtual functions are (of course) important in a situation such as the OP described, with inheritance-based polymorphism.

They are indeed. I just feel the OP needs a language-neutral OO primer more urgently than implementation details. Problem is that OO design is a whole field of its own.

[ Start Here ! | How To Ask Smart Questions | Recommended C++ Books | C++ FAQ Lite | Function Ptrs | CppTips Archive ]
[ Header Files | File Format Docs | LNK2001 | C++ STL Doc | STLPort | Free C++ IDE | Boost C++ Lib | MSVC6 Lib Fixes ]

hm.. simple examples... maybe from real life...

theres a base class EnergyComponent, containing a lot of things (cost, weight, reacharge time, energy used, functions to recharge and calculate how effective they work depending on how much energy the get)...

then you have a lot of stuff like: shields, weapons, engines, sensors etc...

so lets pretend you found a bug and have to change/rewrite the recharge-function. if your stuff inherits from the base class you will change ONE function. if you dont you will have to change the code for every single class.

also: imagine a shop thats selling equipment.
inheritence: the shop has a list of EnergyComponents.
no inh.: the shop needs a seperate list for every kind of equipment (shields, guns, missiles, engines, target computers, and anything you can think of).

and now go one step further and imagine all the different kinds of weapons, that would either simply inherit from the class or make you cry out loud everytime you find a bug ,-)