Inheritance, Composition, and everything in–between

There are many concepts in the OOP paradigm. Inheritance is the most known, and it allows us to model software as relations between objects, just like in real life.



But it has some drawbacks, which alternative paradigms can fix. Let’s dive into OOP, inheritance, and everything in–between.

# Object oriented programming
Object oriented programming, or OOP in short, is probably one of the most popular programming paradigms. It’s an easy paradigm to understand, because it follows the way we, humans, are seeing the world.

For us—the world is a collection of objects that can be modeled in software. Let’s say a car. A car consists of the engine, a set of tires, a chassis, a steering wheel, seats, etc. In code, this would look something like this:

```typescript
class Engine {
	function goVroom() {}
}

class Tire {}

class SteeringWheel {}

class Car {
	private engine = new Engine();
	private tires = [new Tire(), new Tire(), new Tire(), new Tire()];
	private steeringWheel = new SteeringWheel();
}
```

## Inheritance
We can’t talk about OOP without mentioning inheritance. Let’s look back at our car example. Say we want to output the parameters of our car. For the sake of simplicity, let’s omit the `Engine` for now.

```typescript
class Tire {
	private radius: number;

	public function getInfo() {
		return `Tire Radius: ${this.radius}`;
	}

	get circumference() {
		return 2 * Math.PI * this.radius;
	}
}

class SteeringWheel {
	private radius: number;

	public function getInfo() {
		return `Steering Wheel Radius: ${this.radius}`;
	}

	get circumference() {
		return 2 * Math.PI * this.radius;
	}
}
```

We can notice some repetition in there. If only there was a way to specify that both the `Tire` and `SteeringWheel` are forms of a `Circular` object. Welcome—Inheritance.

```typescript
abstract class CircularObject {
	constructor(protected radius: number) {}
	
	get circumference() {
		return 2 * Math.PI * this.radius;
	}
}

class Tire extends CircularObject {}
class SteeringWheel extends CircularObject {}
```

Inheritance allows us to define common behavior and functionality, as well as common interface. We can enforce, through inheritance, that all object that inherit from `CircularObject` will have a `radius` property, and a `circumference` property, which is calculated. I’m not going to go too deep into inheritance in this post, though.

## Where inheritance fails
Inheritance, however, has one big pitfall—multiple inheritance.

Let’s say we have the following code:

```typescript
abstract class Fruit {}
class Plum extends Fruit {}
class Apricot extends Fruit {}
class Pluot extends Plum, Apricot {}
```

> [!fact]
> Pluot is a real crossover between plum and apricot. It has high sugar levels and extraordinary sweet taste.

If you try to “compile” that code, you will get an error:
> Classes can only extend a single class.(1174)

And it’s worth mentioning that this is not some weird constraint of a Typescript compiler. Apart from C++ (and apparently python), no other major language supports multiple inheritance. Why you ask? There is one problem with it.

### The diamond problem
One of the biggest drawbacks of multiple inheritance, is that it can lead to one particular problem knows as—the diamond problem. Let’s try to visualize the above inheritance as a relations graph:

```
	Fruit
	 /\
	/  \
   /    \
 Plum  Apricot
   \    /
    \  /
     \/
    Pluot
```

As you can see, this inheritance creates a diamond-like shape. The shape itself is not the problem, but the problem lies in an underlying implementation ambiguity one can introduce. Imagine that everything we inherit from `Fruit`, needs to implement an abstract method called `getColor`:

```typescript
abstract class Fruit {
	public abstract getColor(): string;
}

class Plum extends Fruit {
	public getColor() {
		return 'purple';
	}
}

class Apricot extends Fruit {
	public getColor() {
		return 'yellow-orangish';
	}
}

class Pluot extends Plum, Apricot {}
```

Since `Pluot` extends non-abstract classes, it is not obliged to implement the `getColor` method. Assuming multiple inheritance was possible in Typescript, what would be the output of:

```typescript
const pluot = new Pluot();
console.log(pluot.getColor());
```

It’s impossible to know. This ambiguity is hard to mitigate. In complied language—it’s usually forbidden at the compilation level, either via explicit error during class inheritance definition, or during invocation. The latter enforces the invocation to be explicitly cast to a specific type, for example:

```java
Pluot pluot = new Pluot();
System.out.println((Apricot)pluot.getColor()); // yellow-orangish
```

> [!note]
> Java does not support multiple inheritance either, so this code is for demonstration purposes only.

Another approach some languages take—is a compile time requirement to re-implement the method in the grand-child class, thus eliminating the ambiguity.

However, in case of dynamic languages—nothing guards your types. In–fact, the JavaScript runtime doesn’t know about your `Apricot` and `Pluot` objects. All it sees are `Object` types with a function on their prototypes. In this case, Typescripts compiler is the one guarding you. And Typescript, as well all know, is just a syntactic sugar on top of JavaScript.

## But what about interfaces?
Apart from abstract classes that can contain both interface and functionality, there are also what is known as Interfaces or Protocols. An interface is just a definition of an agreed upon API. It defines the API, but does not allow implementation in the body of the interface. It’s up to the object that implements the interface—to provide the actual implementation.

Therefor, it’s possible to create a diamond like relation graph with interfaces. Consider the following example:

```typescript
type Target = ...;

interface Clickable {
	getTarget(): Target;
}

interface Moveable {
	getTarget(): Target;
}

class Ball implement Clickable, Moveable {
	getTarget() {
		const target = ...;
		return target;
	}
}
```

Since neither `Clickable`, nor `Moveable` provide the actual definition, it is perfectly fine that the ambiguity exists, and it does not create any problems, since the compiler has no confusion.

The same is true for this scenario:

```typescript
interface Moveable {
	move();
}

class Ball {
	move() {
		...
	}
}

class Basketball extends Ball implements Moveable {
}

console.log((new Basketball()).move());
```

This code complies and runs perfectly, because from the view point of the compiler, `Basketball` conforms to the interface `Moveable` since it inherits the `move` method from `Ball`.

There are some more interesting cases, such as: what happens if the signature of `move` in the `Moveable` interface—is different from the `move` in `Ball`? Would you be able to both extend from `Ball` and implement `Moveable`? Which version of `move` then will be called?

I don’t want to spend more time on OOP and inheritance. Drop me a message/email (contact details down below this post) if you are interested to read more about those weird cases in Typescript. For now, let’s move on.

# Mixins
As we’ve seen earlier, multiple inheritance is a big no–no. However, there are legit cases where we want to inherit functionality from multiple classes. A great example is the game development industry. It’s common to think of game objects as, well, objects. Let’s say we are trying to build a modular system of NPCs (Non Playable Character—represents a game character that is controller by the game/AI and not by the player).

We have some NPCs that can move. Some NPCs can take damage. Not all NPCs are going to take damage. The local town potion seller—should not be attackable by the player. An evil orc or mimic chest—should be able to take damage. The chest however can’t move, because it’s, well, a chest.

I bet in your head you already have an inheritance graph. Let’s try to model it.

```typescript
class Moveable {
	constructor(private positionX: number, private positionY: number) {}

	public moveTo(x: number, y: number) {
		this.positionX = x;
		this.positionY = y;
	}
}

class TakesDamage {
	constructor(private health: number) {}

	public takeDamage(damage: number) {
		this.health -= damage;
	}

	public isDead() {
		return this.health <= 0;
	}
}

class MimicChest extends TakesDamage {}

class PotionsSeller extends Moveable {}

class EvilOrc extends TakesDamage, Moveable {}
```

Oh-no! The evil orc is trying to do multiple inheritance. Even though it does not introduce any ambiguity, like we’ve seen before, multiple inheritance is still forbidden. What can we do?

Meet—Mixins. Mixin is a way to have reusable code, like our `Moveable` and `TakesDamage` classes, without having the end class to inherit both, hence avoiding the diamond problem.

A common way to implement a mixin, is by creating functions that return an anonymous class. In our case, it will look something like this:

```typescript
type Constructor = new (...args: any[]) => {};

function Moveable<TBase extends Constructor>(Base: TBase) {
	return class extends Base {
		_positionX = 0;
		_positionY = 0;
		
		moveTo(x: number, y: number) {
			this._positionX = x;
			this._positionY = y;
		}

		get x() {
			return this._positionX;
		}
		
		get y() {
			return this._positionY;
		}
	}
}

function TakesDamage<TBase extends Constructor>(Base: TBase) {
	return class extends Base {
		_health = 0;

		takeDamage(damage: number) {
			this._health -= damage;
		}

		get health() {
			return this._health;
		}

		get isDead() {
			return this._health <= 0;
		}
	}
}

class NonPlayableCharacter {
	constructor(private name: string) {}

	getName() {
		return this.name;
	}
}

const EvilOrc = Moveable(TakesDamage(NonPlayableCharacter));

const orc = new EvilOrc("sluggish");
orc._health = 10;

console.log(`Orc ${orc.getName()} is located at ${orc.x},${orc.y}`);

orc.takeDamage(20);

console.log(`Orc ${orc.getName()} took 20 points of damage and is now ${orc.isDead ? 'dead' : 'still alive'}`);
```

The output of this program will be:

```shell
Orc sluggish is located at 0,0
Orc sluggish took 20 points of damage and is now dead
```

And as you can see, our `EvilOrc` class was able to inherit from two classes! There are some drawbacks, as you probably noticed. For one—any mixin must have a generic constructor with `...args`. Attempt to add a non-generic constructor to a mixin will result in error `TS2545` that says:

> A mixin class must have a constructor with a single rest parameter of type 'any[]'.

So all the benefits of hidden fields, or initialization—are thrown away. One way to at least remove some code duplication, is to have factory methods:

```typescript
type Vector2D = {x: number; y: number};

function createOrc(name: string, initialHealth: number, initialPos: Vector2D) {
	const orc = new EvilOrc(name);
	orc._positionX = initialPos.x;
	orc._positionY = initialPos.y;
	orc._health = initialHealth;

	return orc;
}

const orc = createOrc("sluggish", 10, {x: 10, y: 10});
```

But data access is still not protected. Fields can’t be marked as private, because then you lose access to initialize them, and need to provide a setter method—which in this case beats the entire purpose of making the field private in the first place.

However, if you have common functionality that you want to share to between multiple objects, and don’t care much about encapsulating the properties—then mixins are a great way to do that.

> [!note]
> There is a way to define mixin through prototype inheritance. It’s ugly. But if you want to take a look, there is an example in the [Typescript Handbook](https://www.typescriptlang.org/docs/handbook/mixins.html#alternative-pattern).

As we’ve seen, with mixins you lose the encapsulation, and more over, you can encounter weird bugs like prototype overrides! Consider the following example:

```typescript
type Constructor = new (...args: any[]) => {};

function Plum<TBase extends Constructor>(Base: TBase) {
	return class extends Base {
		getColor() {
			return "purple";
		}
	}
}

function Apricot<TBase extends Constructor>(Base: TBase) {
	return class extends Base {
		getColor() {
			return "yellow-orangish";
		}
	}
}

class BasePluot {}
const Pluot = Plum(Apricot(BasePluot));
const p = new Pluot();
console.log(p.getColor());
```

What would be the output? The correct answer is `purple`. However, if we switch the order if the mixin composition from `Plum(Apricot(BasePluot));` to `Apricot(Plum(BasePluot));`, the output now changes to `yellow-orangish`!

And what if we want to define a color for our `Pluot`?

```typescript
class BasePluot {
	getColor() {
		return "red"
	}
}
```

You won’t be able to access it, since mixins are based on prototype overriding.

Last, but not least—have you noticed that we need to have 2 classes for every object we want to construct? In order to create a `Pluot`, which is composed of `Apricot` and `Plum`, we need to have both the `BasePluot` class, and the result of the mixin composition call. And how the heck do we create an instance of Plum or Apricot? That’s how:

```typescript
class ApricotBase {}
const ApricotClass = Apricot(ApricotBase);
const a = new ApricotClass();
```

Such a mess. Imagine testing a mixin, you will need to define a dummy class just to be able to instantiate the mixin itself. Mixins are better reserved for small pieces of reusable code that needs to be composed. In a real scenario, like a game—they are hard to maintain.

# Composition
Lastly, we come to Composition. Composition, as the name implies, is used to compose objects from reusable code pieces, rather than leveraging inheritance. Mixin is a form of composition, but it still relies on inheritance to combine shared functionality into one class.

You’ve probably used composition many times in your development, without even knowing it. The `Car` example at the top of the article uses composition, to compose one specific object—the `Car`, using other reusable objects like `Tire`, `Engine`, etc. But this composition approach does not help us with our `EvilOrc` example. We could do something like this:

```typescript
class Moveable {
	...

	moveTo(pos: Vector2D) {
		...
	}
}

class EvilOrc {
	private moveable = new Moveable();

	moveTo(pos: Vector2D) {
		this.moveable.moveTo(pos);
	}
}
```

But it's ugly, and repetitive.

When building an architecture around composition, we no longer think of objects and their properties—as inheritance tree. We don’t say that an Orc is a Moveable object, and an object that can take damage. Instead, we say that an Orc **has** the ability to move, and to take damage. It’s a small change in wording, but a totally different concept. Let’s try to redefine our `Moveable` and `TakesDamage` classes, to better suit composition.

First, we need to define some utility types:

```typescript
abstract class Component {}
type ComponentFunction = Function;
type ComponentClass<T extends Component> = new (...args: any[]) => T;
```

With composition, we need to distinguish between the composable objects, and the composed objects. In our case, `Moveable` and `TakesDamage` are reusable classes that have no meaning outside a context of a game object. We can create an instance of `Moveable` class, but it has no meaning by itself. Therefor, we will separate those containers of common logic, into what I’ll call a `Component`. Hence, the abstract `Component` class. The two types are used for some type inference, and their role will be clear in a bit.

Next, let’s rewrite our `Moveable` and `TakesDamage` as components that will be composed, and at the same time, rename `TakesDamage` to `Health`:

```typescript
class MoveableComponent extends Component {
	constructor(private position: Vector2D) {
		super();
	}

	public moveTo(pos: Vector2D) {
		this.position = pos;
	}
}

class HealthComponent extends Component {
	constructor(private health: number) {
		super();
	}

	public takeDamage(damage: number) {
		this.health -= damage;
	}

	public isDead() {
		return this.health <= 0;
	}
}
```

Now, we marked some classes as components. Before we can finally define our `EvilOrc` class, we need one more utility class:

```typescript
abstract class GameObject {
	private components = new Map<ComponentFunction, Component>();

	protected addComponent(component: Component) {
		this.components.set(component.constructor, component);
	}
	
	hasComponents(components: Iterable<ComponentFunction>): boolean {
		for (const c of components) {
			if(!this.components.has(c)) {
				return false;
			}
		}
		return true;
	}
	
	getComponent<T extends Component>(componentClass: ComponentClass<T>): T {
		return this.components.get(componentClass) as T;
	}
}
```

This class will serve as the base class for all our game objects, and it has a list of components. Hence, composing them into a game object. Here, the types `ComponentFunction` and `ComponentClass` are used for some Typescript magic.

Lastly, we need to define our `EvilOrc` and `MimicChest`:

```typescript
class EvilOrc extends GameObject {
	constructor(initialPosition: Vector2D, initialHealth: number) {
		super()
		this.addComponent(new MoveableComponent(initialPosition));
		this.addComponent(new HealthComponent(initialHealth));
	}
}

class MimicChest extends GameObject {
	constructor(initialHealth: number) {
		super()
		this.addComponent(new HealthComponent(initialHealth));
	}
}
```

And voilà! As I’ve said earlier: `EvilOrc` is not **a** `Moveable` and `Health` object. Instead, `EvilOrc` **has** the ability to move, and **has** health (and hence—ability to take damage, in our case).

*Okay*—you say. *But what do I do with this? How do I operate on this?* Let’s say we are trying to build a sequence that will perform an attack by the player, on a NPC. This might look something like this:

```typescript
function performAttack(go: GameObject, damage: number) {
	if(!go.hasComponents([HealthComponent])) {
		throw new Error('game object does not have health component');
	}

	const h = g.getComponent(HealthComponent);
	if(h.isDead()) {
		throw new Error('game object already dead');
	}

	h.takeDamage(damage);
}
```

It’s a very modular system that allows you to compose all kinds of behavior. It’s widely used in game development, and is knows as ECS—Entity Component System. I was never able to find use-cases for it outside of game development, but recently I had the chance to use a similar implementation at my work. I thought it’s worth sharing this with you, and maybe you can find a good use cases for it as well.

Imagine for example that you want to build a highly reliable weather service. It has to depend on multiple external weather APIs, because you want to fallback to a different API if one is down, or takes too much time to answer. But not all weather APIs might support the features you need. One might support temperature and wind conditions; another one will support temperature and precipitation; while the last might support all of them: temperature, wind condition, and precipitation. This example might be a prefect use case for the aforementioned composition. The implementation of such system, using composition—will be clean and easy to maintain.

Remember—good developers have a lot of tools, and try to use the best one for each scenario. Happy coding!

There are many concepts in the OOP paradigm. Inheritance is the most known, and it allows us to model software as relations between objects, just like in real life.



Programming

Latest Posts

Inheritance, Composition, and everything in–between