Abstraction Can Make Your Code Worse

You have a game where you have a main character, enemy characters and obstacles.

For each of these objects we need to have code that keeps track

of its position in the world and code for rendering the image for each object.

We could write the same code in all three classes,

but you recognize that this is all similar.

So instead you make a third class called Game Object that handles this for you.

You now have a general implementation that tracks and renders out the object.

The code is mostly identical, but you allow the subclass to specify

which image is shown.

You just created an abstraction.

Architects have gotten really good at this game

of identifying repetition and extracting it out.

We get into the mode of code repetition bad, more abstraction good.

But there's a hidden tradeoff that doesn't get considered: Coupling.

Most engineers conceptually understand what coupling is,

and they definitely feel its web when trying to modify an over coupled system.

But when designing software, you don't feel

the impacts of coupling.

I consider coupling to be an equal and opposite reaction of abstraction.

For every bit of abstraction you add, you've added more coupling.

Let's explore an example.

We have a program that saves out data to XML, but that's the old format.

So we want to move to JSON.

We could do this by adding a configuration to the save logic

to support both modes.

But this will make the removal

of XML complicated and dangerous

because they're all intermingled.

So instead we'll make the JSON writer a separate class.

Then we can just chop off the XML support by deleting the whole file,

not needing to unweave the program logic.

All right, so now we've written our fancy new JSON writing class.

We might notice that both take in a file name during construction.

Our little repetition detectors go off and realize that maybe.

Maybe we could extract this out.

So our instinct is to create a common class called file saver

that just takes the file name, and our subclasses can grab it

from this protected variable.

But this is a bad idea.

We've now coupled both of these classes to the same input.

They must take a file input.

So if there ever became a need to create something that didn't use a file

like a database or cloud connection, this would break the abstraction.

And on the flip side, this abstraction brings us no value.

What does this abstraction save us?

Well, I guess we don't need to assign the variable twice.

But this isn't any complicated logic.

It's simply assigning a variable.

So for me, this squarely fits into the not worth it camp.

Okay, now what about the save functionality?

We could consider creating an interface that represents the “save” method,

but we do know that this would increase coupling because now

both of these classes are constrained to the same save method.

So what benefits does this abstraction bring us?

Well, let's look at the usage.

We have an if statement that decides which class

to create and calls save on one of them.

So if we add a common interface,

we only get to remove this one duplicate save line.

That doesn't simplify the program in any meaningful way.

So I'd also put this into the it's not worth it camp.

At this point it's better to keep these as two distinct classes

with no connection at all.

There are two cases where it would make me decide it was worth it.

One would be if we added more save options.

If we had three or more we might want to extract the construction

of these save objects into a separate piece of code, especially

if the different savers had different parameters, like a database configuration.

The other case would be if we needed our program to defer

or repeat saving at a different point in the program.

For example, if we wanted to save every 5 minutes

automatically, we’d create a class called “IntervalSaver”,

and it would make sense for this Interval Saver class

to be unaware which saver it's calling.

In both cases, it becomes worth it when we want to separate the decision

of which saver we want from the time we actually want to save.

Overall, it's good to only apply abstraction

when the value it brings overweighs the coupling.

This does mean that you might have a little bit of code repetition.

But I think that a little code repetition

brings less pain when changing code than over coupling.

What do you think?