Reusability vs. Inheritance
Tags: javascript, programming, oop
Published: 2023-05-31 12:25:09

One of the most valuable - and often *under-estimated* - principles of OO is inheritance. Frameworks like React claim to enable code ***reusability***, but it is important to see, that ***inheritance*** goes much further than this. 

**So, what precisely is the difference?**

First of all it might be helphul for clarify the general terms. I´m talking about a class concept used by C++ or Object Pascal. The Javascript class concept is similar, but lacks some important features to protect data against external access. 

A ***Class*** is a template for ***a closed unit consisting of variables and functions***, called *"properties"* and *"methods"*. 

A class is only a "blueprint". To get some working code you need to create ***instances*** of the template, called the ***"Objects"***. (*This is different from Javascript, where objects are simply an arrangement of variables. This arrangements would be namend Structures (struct) in C++*). Each object shares the same methods (= internal functions), but has an individual set of porperties that is preserverd during lifetime of this object. 

In practice, this is a very efficient way to organize code: While all objects have the same "methods", the code needs only to be stored once. In fact, an object just contains a pointer to the class definition. So, each object has its **individual set of data** (*properties*), but **shares the same methods** with all of it's siblings.

###Building a family

For now, we have seen what classes and objects are, but what is inheritance? **Inheritance** let´s you create new classes, that "inherit" all methods and properties from a "parent"-class. Javascript uses the "extends"-keyword to define child classes. In C++ the "parent" is just named after a child class definition. Both languages also know multiple inheritance, where more than one parent can be named. 

A child "inherits" all methods and properties of it´s parent, so without any further definitions the two classes would be identical. But usually, you build a child class to apply some changes to the initial behavoir. There may be new definitions in the child class, that "extend" the function of the parent class.

*Here comes the interesting part:* A child may not only add new properties, it may also change the behavoir of existing functions. A PAINT-function, that painted a **dot** in the parent class, may now draw a **circle**. PAINT() may be called from different other methods inside the parent class (*or even somewhere in an ancestor of the parent*). If you call it from inside the parent, PAINT() will still paint a dot, but if you call it from within the child, it will paint the circle. So you can change the behavoir without changing the parent, preserving most of it´s functionallity and without causing unwanted side effects. Often it is not even necessary to know much about the parent to introduce changes. It is sufficient to just know the part you are changing. 

Inheritance is a clever way to extend the behavoir of an existing class, without changing the class itself. There  might be other classes the derive from the same parent class. If you would change the parent to enable a different behavoir, you might change something that is important in some of these siblings. This could easily cause errors. You can follow the rue: "Never change a winning team", but at the same time, apply changes to extend the class. 

## Never change a winning team!

"Never change a winning team" is one reason, why creating classes is hard work. You have to design the base classes toroughly, as it causes a lot of trouble if you need to apply changes later. 

It is important to see, that ***inheritance is a relatively lightweight feature***. To inherit from a parent class, the child just needs to contain a pointer to the parent class. Methods, implemented somewhere in the family tree are only written once. If you need to apply fixes to the code, there is only one place that needs to be fixed. 

In C++, Class hierarchies may be huge. To let an element be part of the Windows GDI, classes are often derived from the GDI itself (or of a type library, that is provided by the GDI), inheriting some 10.000 methods and properties in tenth of levels of inheritance. Deriving a class from such a library make the class part of this family. 

Some people say: Why do you need the whole forest and a gorilla, if you only want a bananna? The truth is: You still only buy the bananna, but this bananna knows, where the forest is (and the gorilla). [see also...](https://dev.to/efpage/what-s-wrong-with-the-gorilla-2l4j)


![chimpanzee](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vnsvias3qygip0cpyxs5.jpg)