Phils quick-n-dirty intro to object-oriented thinking #6 - inheritance

This chapter is not done yet. [last updated, march 30, 2009]

In it, I will discuss object inheritance.

If it is not done in a month, bug me please :)


The concept of "inheritance"

In OOP, there is is a concept of "inheritance", between a Parent, and a Child, object. In programming languages, the inheritance consists more of what the object is, rather than what the object possesses.

There is still the concept of "possessing" a set of functions for data manipulation of the object. In that sense, children of an object, usually "inherit" all the functions that a parent possesses.

Bad vs good choice of object types

People can sometimes get carried away with object inheritance.

An example of bad object inheritance

Let's say for some reason, you have to have representations of certain physical things. The things you happen to care about, are elephants, and oranges. Your first impulse might be to make a object class "Thing", that is a class that could represent both an Elephant, and an Orange.

Class Elephant, and Class Orange, would then both "inherit" being a type of class "Thing"

To do anything useful with either an object of class Elephant, or class Orange, you would need some very specific operators. For example, "ThingElephantFeed()", and "ThingOrangePeelit()". However, it makes no sense to try to use ThingElephantFeed(), if the object is currently representing an Orange. Because of this, "Thing" would then need special status queries, "isElephant()", and "isOrange()", to determine which would be the "right" operators to call on it.

This would certainly work. But it is very poor design. Firstly, it requires the programmer to know what this object "really" was, in order to call the "correct" functions for it.

Secondly, what would be left in Thing, that would be common to both Elephants and Oranges? Unless you are doing some very unusual modelling, the answer is probably "nothing". This indicates that they should not share a common parent class, since they have nothing functionally in common.

There is no reason in this simplified case to make an elephant, and an orange, share a common class. If you are set on making more general classes before creating Elephants and Oranges, it might make more sense to have an Animal class, and a Food class (based on the assumption that down the road, you would be interested in more types of animals, and more types of food object. Then Animal would have a "Feed()" function, and Food could have "ShedWrapping()" function.

Once again, if you find yourself using a single object type, in vastly different ways, for different instances of objects, you probably should not be using a single object type in the first place.


I hope this has been useful to you. If you'd like another chapter added, email the author, below, with a suggested topic.
Previous section: Game-plan summary
OOP Table of Contents --- phil@bolthole.com
Part of bolthole.com... Solaris tips ... ksh tutorial ... AWK Programming tutorial