If you’ve been eying the opportunity to become a computer programmer for some time now, or even if you’ve just started venturing out onto this great and noble journey, chances are that you’ve hit yourself with this term quite a few times whether in books, booklets or even documentation sites, Classical inheritance has always been there, ever present.
So what exactly does it mean? What does this term – that sometimes has had even seasoned programmers on the ropes – actually express?
Def- Class-based programming, or more commonly class-orientation, is a style of object oriented programming (OOP) in which inheritance is achieved by defining classes of Objects, as opposed to the objects themselves (compare prototype based programming). – wikipedia
So let’s break it into parts. First off we start with Inheritance.
Now, even If you are not a programmer, you’ve heard or even seen this term applied in real life. In non-programming situations, the institution of Inheritance defines the laws and rules applied to the transfer of goods or traits from one person to the next. We usually see it most often applied on the case of a testament reading and application. The family of the deceased – usually the children – inherit his or her patrimony, both active (meaning goods and income) and passive (meaning debt and taxes).
The other scenario is with body traits and possibly behavior. You often hear stuff like – “He has his mother’s beautiful blue eyes” or “She has her father’s temper and drinking problem”. We contextualize the statement as if the child inherited physical traits and behavior from one or both parents.
Here lies the problem. Because of our previous experience and connotations with the term, we have a presupposition in place, and often it messes with our understanding of Classical Inheritance in OOP.
In OOP, one Object only ever inherits directly from just one other. Understand this simple sentence and you’re journey into programming will be much much easier.
I’ll say it once again, just to be sure the message got across. In OOP, class A inherits from class B , but not from class C. You do not have simultaneous inheritance.
You do however have multi class inheritance, kind off, but via a step system, not direct.
If you remember the guiding SOLID principles of design, you place your core business logic in abstract Objects and trickle down specifics in other Objects. This, for example, is how RUBY is written and designed. You have class Object, which is the root of Ruby’s class hierarchy. Its methods are available to all classes unless explicitly overridden. But Object also has a parent. It inherits from BasicObject. It is the parent class of all classes in Ruby. It’s an explicit blank class.
So when you define class A, this specific class inherits from Object, it’s default parent, and thru the fact that Object inherits from BasicObject, class A also inherits, indirectly, from BasicObject.
So when you read a phrase stating that “X class inherits from it’s parents”, in reality X only inherits from 1 direct parent, and the rest indirectly.
This is a important concept to grasp since knowing it, you can use and successfully apply the concept of Blank Slates.
If you are unfamiliar with the term, a blank slate is basically an empty Object. It comes in handy when you want to settle an Object hierarchy (for purposes which shall be announced later in a post on metaprogramming) but you do not want to inherit any behavior. So you use a dumb object
A simple example would be if you want class A to have a method that conflicts with a preexisting method already defined in the language syntax. So you sidestep the chain of hierarchy and make class A inherit directly from a dunce object, BasicObject
class A < BasicObject
def conflicting_method_name
#......
end
end
Be careful though. It might come in handy, and there are specific scenarios where using a blank slate is very useful, but heavy usage can easily lead to severe consequences.
The second part of the classical inheritance concept lies with the classical part. To better understand what this term signifies you need to understand how it came about.
It is a play-on-words on the “class” name since the concept deals with class inheritance. Think of it like an “insider joke”. It might be funny to those “in the know” but to those just starting of on the great journey into programming, it is counterproductive naming to say the least.
Just take it as a very good real-world example on “the importance of naming” and the consequences bad names have. As a programmer you will spend a boatload of time pondering good names for your objects (variables, methods, classes etc). But more about that in a later post.