Inheritance

Inheritance

T. M. Scanlon’s book ‘What We Owe to Each Other’ actually applies to this fundamental.
At least the title does, however, this is not the philosophy channel, so how does it apply?

If we reflect this title onto the action which it gives rise it becomes ‘What we give to each other’.
Much like in the medical world, inheritance gives something of value from the parent or ‘base class’ to the ‘derived class’.

Do not fear, a derived class is just a class which came from the other.
A child class is another term for a derived class, as is a sub-class.

Similarly, a base class is just the class it came from, the parent class.

For consistency I have to mention composition. It is not the same as inheritance, and sometimes has been confused. To help clarify things, you can just imagine the type of relations which the two parts have between each other. With inheritance we see an ‘is a’ relationship, whereas with composition we see a ‘has a’ relationship.

I only want to briefly mention composition here because the contrast helps define both parts. To say that your composition, or code is reusing an existing component you would describe it with a ‘has a’ relationship.

Your composition, let us say, your Cat class ‘has a’ Tail component.
Your composite is the ‘cat class’ and the component is the ‘tail class’ here.
In this case, as animal architects we simply make use of the existing tail component in our cat composition.

What if we want to extend this Cat class into something fiercer like a Lynx.
or perhaps we wanted to make lots of cat-like classes, but didn’t want to reuse any ‘Purr()’ or ‘Pounce()’ code.
_

Inheritance can help make this task clear and fun!
Say we are given a Cat class

Perhaps you, a brand-new architect in the Codedverse have been tasked with designing some new cats.
After watching that there TigerKing you know that you want to recreate them, and no one could ever forget the majesty of the Lions. We also want a Lynx, and maybe some brand new cats… some sort of Lion and Tiger mix… a Liger… wait, they have that already? … sometimes animals do their own coding.

In the case of the Liger, it would be an example of Multiple Inheritance it has inherited attributes from both the Lion and the Tiger. If it were true multiple inheritance you could be correct to say that a Liger is both a Lion and a Tiger.

This example is not perfect since a Lion and Tiger share the same base class, however, as a generalization it demonstrates the idea well.

~

Here, given the Cat class from earlier,
we are presented with two new classes, and TheAnimalKingdom where they can interact.

We did not have to rewrite how to pounce or purr as it was inherited from the base class.
This is why we see the prefix ‘base.’ when we call the inherited functions.

In this case, SuperPurr() and SuperPounce() are part of the Lion and Tiger class respectively.
If we imagined creating that Liger where we inherited from both the Lion class and the Tiger class, looking past the scenario I mentioned, we would then see a new animal which could both SuperPurr() and SuperPounce() along with the base Purr() and Pounce() functions which were inherited.

Key take away: In keeping with the Object Oriented paradigm, do not rewrite the wheel class!
Inheritance allows us to keep our code clear and concise. Using heredity, we can see all the code in a single spot, and with encapsulation already on the scene what we are presented with is a clearly organized structures of data.