Implementation Inheritance

The class inherits an interface - a set of member function prototypes defining its externally visible usage.

It also inherits any data members or code for those member functions defined in the parent class including construction and destruction code.

More specifically, class operations are delegated to the base unless explicitly overriden.

The class may choose to re-implement the member functions defined in order to become differentiated in behaviour from the parent, although in some languages I believe this can be forbidden. Is this true?

A method can be marked to prevent overriding (Java uses the "final" keyword for this). In some languages this is default behaviour.

If the parent class is abstract, the child class will be abstract unless it defines enough members to become concrete. On the other hand, a child class of a concrete class could declare -- but not define -- additional methods, thereby becoming abstract.

-- KatieLucas

I think the issue here is the way that each level of inheritance may add additional functionality to the object creating method bloat (at least at the exposed levels). I have an object I am currently working with that has 60+ methods/interfaces after two levels of inheritance (yes, a serious case of Refactoring is needed). Some of the methods that are being added to the more specific daughter class may eventually need to be refactored out into a separate class that will become a variable used with the final object. If my object (call it BloatClass) is concerned with manipulating a set of data and I just add here and there along the class tree small functions that would enable sorting, I may be able to abstract those functions out of BloatClass into a separate interface or object variable and streamline the inheritance path at the same time creating more reusable code -- and in this case, if I am able to abstract out a sorting class, I probably already have a base class to build that new sorter out of anyway. WyattMatthews