View source for OOP - Abuse of Inheritance

{{#seo:
|title=OOP - Abuse of Inheritance
|titlemode=replace
|keywords=OOP, Object Oriented, Single Purpose
|description=A discussion about the abuse of inheritance in OOP
}}
{| class="wikitable" style="text-align:center;width:100%;font-size:70%"
  !style="width:33%;height:10px;"|
  !style="width:33%;height:10px;"| [[Main Page]] &#8683; Up
  !style="width:33%;height:10px;"| [[Software Development]] &#8680; Next Topic
  |-
  |style="width:33%;height:10px;"| Previous Page &#8678; [[OOP - Single Purpose Class]]
  |style="width:33%;height:10px;"|
  |style="width:33%;height:10px;"|
|}
''' Under Construction '''

= Abuse of OOP Inheritance =

== Intent of Inheritance ==
The intent of inheritance in OOP is to allow common functions and member variables to be shared
when two child classes are subtypes of a parent class. Subtype means it is a refinement of the parent class,
not a separate entity. For example
<pre>
class Animal:
    def __init__(self):
        self._has_hair = None
        self._heart_chambers = 0
        self._produce_milk = False

class Mammal(Animal):
    def __init__(self):
        super().__init__()
        self._has_hair = True
        self._heart_chambers = 4
        self._produce_milk = True

class Reptile(Animal):
    def __init__(self):
        super().__init__()
        self._has_hair = False
        self._heart_chambers = 3
</pre>

Both Mammals and Reptiles are animals and are similar. But Mammals produce milk while Reptiles don't.

A main feature of inheritance is the ability to pass an instance of a child as its parent.
To ensure that's possible the Liskov Substitution Principle must be followed or subtle bugs are will occur.

https://en.wikipedia.org/wiki/Liskov_substitution_principle

For example, if there is some code that works with any animal, then it must be possible to pass a Mammal
or a Reptile instance to that code without any failures. In general that means that the calling code ONLY
uses the functions and member variables of the parent class.

== Misuse of Inheritance ==
Inheritance allows any code in the parent class to be shared among all child classes. This a great convenience
but leads to misuse.

For example, one real world app was made of 3 classes. Two were legit, but the third class was called Generic.
Both of the child classes inherited from Generic and so could use any function in there. In other words,
the Generic functions were globals.

Eventually another class was added and needed a couple of functions in Generic, so it became a parent class
for it as well.

Each instance of the child classes had its own instance of Generic. That means that common member variables in Generic
were not shared between the child classes. That led to workarounds and finally to the creation of a Singleton
that Generic would use and thereby get around a "limitation" of inheritance.

Over time, Generic had nearly a thousand functions in it. Why? Because it was very difficult to tell if a function
already existed, so developers just created new functions. And so common functions existed and
were named with similar names... or not. Reading the calling code was difficult since similar named functions behaved
differently and differently named functions behaved similarly.

When a bug was found in one function, it was fixed there but not in the other common similar functions, usually
because no-one knew where they were. That led to odd bugs where "the issue was fixed" but still occurring. Why?
Because one caller used one of the common functions and another caller used another common similar function.

In short, Generic was a dumping ground used for convenience.

== How to recover ==
Refactor, over and over again.

* convert Generic (to use the example above), to an independent class and have a singleton instance of it. This means that any member variables are shared across all classes. And use this opportunity to remove this as a parent from Generic.
* reshuffle the layout of the functions inside Generic. Start to cluster common behaving functions into an area of the file. This will make finding common similar functions easier to do. (Note: when we did this, we found nearly identical functions but with different names).
* refactor common similar functions into smaller functions. Look through as many existing functions as possible to replace common code with these new, smaller functions. This will clearly demarcate the differences between functions.
* track these smaller functions and see if there is a potential for creating a class to encapsulate their behaviors.
* determine if a function is strictly used by only one child class and not any others. Move that function to the child class.
* extract out as many classes as possible from Generic to break down the code into smaller pieces. The callers will then use local instances of these new classes, or they can be made shared singletons as well.