This is part 3 of a series. To get the most out of these posts, read them in order:
Part 3: Single Inheritance versus Multiple Inheritance
In the first 2 sections, we talked about how in OOP, everything is an Object, and using Inheritance, one object can belong to a Class, which “inherits” the states/attributes and methods/actions of it’s Parent Class.
For example, the “Toddler Son” Class inherits the “Unconsciously Dance When Eating Something Yummy” method from the “Rails Mama” Parent Class.
But wait–the Toddler Son Class has more than one parent! It also inherits from the “Anti-Geek Papi” Class. That’s where the “Love for all things with wheels” attribute comes from. The Toddler Son Class has Multiple Inheritance!
Multiple Inheritance is just what it sounds like: one class inherits methods and states from multiple Parent Classes.
Multiple Inheritance seems pretty cool, right? If we can control what’s inherited, we can take the good parts of the Rails Mama Class (i.e. “Love of Learning”) plus the good parts of the Anti-Geek Papi Class (i.e. “Ability to Take Everything Apart and Put It Back Together with no Left-Over Parts”), and Voila! Perfect Child Class!
There is one problem, though. Rails Mama and Anti-Geek Papi both have an “Entertain Oneself” method, and those methods, though they share a name and have a similar purpose, are very different.
If we run Rails Mama’s “Entertain Oneself” method, she will go straight to the nearest computer and/or bookshelf. If we run Anti-Geek Papi’s “Entertain Oneself” method, he will start dismantling the nearest car.
If Toddler Son inherits from both Parent Classes, what will happen if we run the “Entertain Oneself” method? Will he dismantle the nearest computer? Read the car manual? Or will the program go haywire, causing him to attempt to flush the cat down the toilet?
Yes, probably the last one. Multiple Inheritance can get quite messy if used improperly, and no one wants Fluffy to take a swirl.
While some languages, (C++, Python and Perl, for example) allow Multiple Inheritance, others (Ruby, Java, and C#) spare Fluffy the bath, and stick with Single Inheritance.
If Toddler Son is an example of Multiple Inheritance, Clone Daughter is an example of Single Inheritance. She takes all of Rails Mama’s methods and states, and none of Anti-Geek Papi’s.
But if we use Single Inheritance, how do we improve on the original Class? Does Clone Daughter have to inherit the “Drive a Car in Reverse” method from Rails Mama? The world would be a much safer place if she doesn’t.
Here’s where Mixins (a.k.a Traits) come in handy.
Instead of making “Daughter” from multiple Parent Classes, we simply clone “Rails Mama” (since she’s almost perfect anyway), and then Mix In the desirable traits from “Anti-Geek Papi”.
To keep Daughter from driving like a lunatic, we would simply create a Module, or “packet of code” that contains all of Anti-Geek Papi’s driving methods, and then we mix those into the “Daughter” class.
There are different ways of doing the mixing, each unique to the language, but the basic idea is “Please don’t let my daughter inherit driving and directional sense from me.”
And that, in an oddly-misshapen nutshell, is Single versus Multiple Inheritance.
Liked this post? See Part 4: Recap & Quiz.