• A class can be either a compile-time concept (such as in Java or C#) or a class can be a run-time object (such as in Python or Smalltalk).
• The inheritance process can happen either at compile-time (such as in Java or C++) or the inheritance process can happen at run-time (such as in Python or JavaScript).
• A descendant can either be limited to inherit from just one parent (such as in C# or JavaScript) or a descendant may be allowed to inherit from any number of parents (such as in C++ or Python).

So what, then, ties it all together? What is a class? What is inheritance? (From the UML manual) A class is the description of both the data structure and the behavior that is shared among a set of objects. And inheritance is the process of incorporating structure and behavior.

Consider this Python code:

class B():
 def b(self):
  return "b"

class D(B):
 def d(self):
  return "d"

instance = D()
instance.b() # "b"
instance.d() # "d"

Are these classes? Is this classical inheritance?

What if I told you that class B and class D are themselves runtime objects? What if I told you that when we access instance.b, Python looks for the name “b” on the instance object, and if it doesn’t find it, then it looks for it on the “D” object, and if it still doesn’t find it, it looks on the “B” object, and so on down the inheritance chain.

Does that process sound familiar?

Next, consider these JavaScript factory functions:

function b() {
 return {
  b: function () {
   return 'b';
  },
 };
}

function d() {
 return Object.assign(b(), {
  d: function () {
   return 'd';
  },
 });
}

var o = d()
o.b(); // "b"
o.d(); // "d"

We may be reluctant to call these classes or classical inheritance, but here’s what we can certainly say:

“d” defines a structure and behavior that is common to a set of objects, and it incorporates the structure and behavior of “b”, which itself defines a structure and behavior that is common to a set of objects.

* * * *

The first thing we need to do is clear up definitions. This topic has become muddied recently. Both “inheritance” and “composition” have very specific and technical definitions, but a popular blogger has invented his own definitions, ones that are very broad and generic and not compatible with the industry standard.

The industry standard definition of “inheritance” (from the UML manual) is “incorporating structure and behavior.” That could take the form of a class extending another class, or an object delegating to another object, or copying properties into another object. Any of these bring about the same result: incorporating structure and behavior.

The industry standard definition of “composition” is “acquiring references to objects.” That is, one object would have a property whose value is a reference to another object.

Given those definitions, composition (acquiring references) is preferred because:

• When you inherit, you typically get access to the base’s internal implementation.
• When you compose, you interact only with the object’s public interface.
• When you inherit, their interface becomes your interface. Client code will come to depend on that, which makes it hard to change your inheritance decision later on.
• When you compose, the private reference is under your control. You decide what interface you want to expose.
• When you inherit, it’s hard to change what you inherit from at runtime (varies by language; JavaScript actually makes this easy).
• When you compose, it’s easy to reassign a different object reference.
• When you inherit, you might be limited to only a single parent (varies by language; JavaScript’s prototype chain is limited to only a single parent).
• When you compose, you can hold references to any number of objects.

As a rule of thumb, use inheritance only when you want polymorphic behavior. “The purpose of inheritance is not for the derived to reuse the base’s code. The purpose of inheritance is to implement substitutability.”