The Flaws of Inheritance

You may have heard the saying prefer composition over inheritance.

The advice is a little vague, so I'm going to break it down.

What is composition, inheritance and why would you prefer one over

the other?

Both composition and inheritance are trying to solve the same problem.

You have a piece of code that you're trying to reuse.

Inheritance is when you have a class that contains functionality you want to reuse.

So you create a subclass extending its functionality.

If you simply extend a class, you've basically created a copy of the class

with a new name, and then you can inject new methods to extend or override parts.

We have a rudimentary image class here.

It represents an RGB image and stores it as a double array of pixels.

The image class hides how the image is stored in memory

and provides a method for looking up pixel values.

We also have some stuff we can do to the image.

We have a resize method which resizes the image by a scale factor,

and we have methods to flip the image horizontally or vertically.

The library

should support JPEG, PNG and bitmap images, but

we also want to reuse all of these methods for the different types of images.

So to support loading and saving these images,

we add two abstract methods: save() and load(),

and then we create the subclass JpgImage,

PngImage and BmpImage.

These subclasses implement their different versions of load()

and save(),

but also get all of the other methods for free.

So when we load a JPEG image or PNG image

we can call resize on it and then we save it.

The resize method is reused for all of the image types.

But when we call load or save the overriden version is called instead.

This works well,

but now we want to create a version of an image

that doesn't come from a file at all, but instead has some methods

that allow the user to draw on the image.

So we create a DrawableImage class and inherit from our parent Image class.

But this

is where inheritance starts to have issues.

The downsides of inheritance is that you've couple yourself to the parent

class.

The structure of the parent is thrust upon the child.

We're forced to implement these to load and save methods

in order to reuse our resize and flip code,

even though they don't make sense for our subclass.

All we can do is have these two methods throw an exception.

To prevent this, we need to remove this method from our parent class

and add a new parent class

in between called FileImage that contains these two methods.

But this also breaks

anyone who currently expects the Image class to contain those methods.

When new changes like this come,

we're forced to edit all our classes, a very expensive refactor.

This is the

greatest downfall of inheritance.

I find it similar to how the ideal cleanness database

schema often causes problems when you scale.

We've moved to NoSql databases with tons of dirty duplication.

Inheritance breaks down when you need to change the code.

Change is the enemy of perfect design and you often paint yourself

into a corner early on with your inheritance design.

This is because inheritance naturally asks you

to bundle all common elements into a parent class.

But the soon as you find an exception to the commonality, it requires big changes.

So our alternative is to use composition.

So what is composition?

You've already been doing it.

Composition is the pattern you're doing whenever you reuse code

without inheritance.

If we have two classes and they want to reuse code, they simply use the code.

Let's

change our image classes to be composed instead.

First, we're going to remove our abstract methods from image.

Now, this is no longer an abstract class.

It's simply a class that represents an image in memory.

In our JPEG, PNG and bitmap classes.

We no longer inherit image,

but we'll keep our save and load methods.

They'll just now be stand alone, not overriding anything.

The methods were accessing a bunch of stuff from the parent class.

So what do we do about those?

Well, instead of accessing them through “this” we’ll

simply pass in the image in question instead.

So now image represents an image

and these other classes cleanly represent a specific file

format.

Now, if our new drawing requirement comes in,

we create an image draw class that takes an image to draw to.

And the methods do their thing.

We're no longer bundled to the file related stuff.

Because we didn't force all the common elements into a parent class

we don't need to alter any of the other classes to add our ImageDraw class.

Now the user no longer chooses the one class that suits their needs.

They also combine classes together for their particular use case.

So here we're loading a JPEG image drawing to it and then saving it.

Another app could do something different, like load a bitmap

image, flip it, resize it, and then save it out as a PNG.

Inheritance is interesting because it actually combines

two capabilities: the ability to reuse code,

but also the ability to build an abstraction.

Creating abstractions allow a piece of code to reuse

another piece of code, but also not know which piece of code it's using.

You define a contract that both sides of the abstraction agree to.

This gives the code

the rough shape of the other code, but it doesn't know exactly what it is.

Inheritance does this by allowing a consumer to think it's taking a class,

but it's actually given a subclass instead.

Then the code can operate like it always does.

Even if the system as a whole is doing something very different.

If we go back to when our image code used inheritance,

our application used the natural abstraction capability of inheritance

by storing references to the parent class.

When our app opens a file,

we just figure out

which subclass to create and then store a reference to it through the parent class.

Then when the user clicks the save button,

our save clicked method will get invoked and we'll just call the save method

and we're abstracted from whether it's the JPEG, ping or bitmap.

But with composition you don't have parent classes.

You're just using the types you want.

Inheritance allows you to abstract because the methods of the parent class

forms a contract.

A contract that says that every child class shall have at least these methods.

So for our new classes without inheritance, we still want to be

able to call our save and load methods without caring about which class it is.

This is where interfaces come in.

Instead of a full parent class with all its variables and methods,

an interface simply describes the contract of what an object can do.

In this case, we'll create an interface called Image File,

which represents the operations an image file can do:

load and save.

Now, like

before, we save a reference to one of our implementations.

But now, through the interface

and when the user click save,

we call save on whatever type was created.

Interfaces are a much more lightweight

way to do this because our interfaces are minimal.

Parent classes share everything by default, making them more difficult

to change.

But interfaces define only the critical parts of the contract

and are easily tacked on to existing classes.

Now that we have a nice abstraction for loading and saving files in our app,

we can actually lift the creation of which image file out of our image app class.

We’ll simply ask the user of the class to pass in the interface instead.

That way this class can just focus on dealing

with the UI commands and the file class can be elsewhere.

There's a name for what we just did there.

Dependency injection.

I'll do a whole video on dependency injection,

but if you've heard the term before and wondered what it was, that's it.

Passing in an interface for what you're going to use.

I won't say that inheritance is as evil as some would say,

but I will say that I almost never use it in my code.

Composition isn't perfect.

You do end up with a lot of boilerplate

needing to initialize all of your internal types.

Many implementations will contain the same code repeated,

and when you need expose information from reused code, you often need to create

a lot of wrapper methods where you simply return a call to an inner type.

But ultimately, composition reduces the surface area

between objects, which gives you less friction as changes come in.

Inheritance might be useful if you're working inside of an existing system

that had highly repetitive code where you only needed to modify one thing.

For example, if you had the need for 100 classes

to conform to some specific interface

which half of them need the same boilerplate over and over again.

You might say that that means that each class has too much responsibility,

and you'd be right.

But changing the plugin model would cost the team months of work.

You might not want to put your effort into that just yet.

If you do use inheritance design the class to be inherited, I'd avoid

protected variables with direct access, like we avoid making our variables public.

For overriding: create an explicit protected

API that you're supposed to override an access mark.

Everything else is private, final or sealed.

This prevents bugs when changing your parent classes

because of not understanding what your child classes have done.