Leaky Abstraction — What Is It?

Spot leakness in your code and see how to deal with it

While designing the architecture more and more abstractions are made, especially in huge and complicated systems. Good quality software should have the right abstractions and one criterium to judge it is making sure that they are not “leaky”.

In this article, I will clarify what abstraction leakness means and propose ways to deal with it.

What is leaking abstraction?

Leaky abstraction is an abstraction that leaks details that it is supposed to abstract away. It happens when at some point user has to know what is “inside” or “under” to operate on abstraction. You certainly face many leaking abstractions in everyday life. If you drive a car you need to remember the fuel level, pay attention to the sounds that come from an engine, and remember to change the oil from time to time. That’s exactly so-called leaking abstractions.

Leaking abstractions can be also found in code — in class implementations, libraries, or protocols. Let’s focus on one code example to understand it better.

Code example

Consider the following code:

It’s a part of an Instagram-like application. The User data structure has a name, uploaded photos, and a list of followers. In the database table users has the following column names: username, user_photos and user_followers.

In order to get users from the database, we need to call getUser(...) with a list of columns (for example ["user_photos","user_followers"] ) that we want to get. The developer implemented it that way because it’s costly to get a list of photos and followers when it’s not needed.

Some ORMs allow us to use lazy loading. It means that the data will be fetch from database only if it’s actually referenced in code (for example you write console.log(user.followers). But this is a naive example without any lazy-loading tricks ;p

Can you spot a leaky abstraction?

In this example database abstraction leaked out of the repository. The developer that is using the repository needs to know that attributes are the names of columns in the database. Also, he needs to know that he does not need to provide a username column as it’s already there. Another leak.

The fix

We can write a function for each combination that is needed:

It surely hides the abstraction but grows a lot when more attributes will come. It may be sufficient for some cases, but in the example, it does not follow the DRY principle.

Let’s try another solution:

In this solution, we create an enum that contains available properties that can be retrieved from the repository in User object. Inside the repository, this enum is mapped for proper column names.

Now developer that uses the repository doesn’t need to know what are the column names. He does not even need to know that they are in a relational database! That’s pretty good abstraction separation.

Now, I hope you got an idea of what are leaky abstractions. Still, there are a few more interesting things about them to talk through.

Law of Leaky Abstractions

Joel Spolsky in his article from 2002 introduced the leaky abstraction topic and formulated the law of leaky abstraction:

All non-trivial abstractions, to some degree, are leaky.

He states that even if we try our best to not leak the abstraction it will eventually leak if we build a complex system.

Does it mean that we shouldn’t care about leaks as some would always exist in our program?

Of course not! Most abstraction leaks need to be fixed, but we should be aware that some are inevitable and we shouldn’t waste time-fighting with them.

Well-known leaky abstractions

Common leaky abstractions that are used by many of us in everyday programming work:

• Iterating over a large two-dimensional array may radically vary in time when doing horizontally vs vertically depending on how elements are stored in a database
• ORMs are great until you realize that there are some things that cannot be done using them — then you need to go one level down through ORM abstraction to write some raw SQL
• SQL performance queries vary according to the way they are written. You need to know a bit about SQL execution to write a good queries

Tips for dealing with leaking abstractions

1. Remove the complexity — More complexity = more abstraction = higher chance of leaks. It’s a good idea to rethink solution architecture if it’s getting too complex and try to find a more simple way.
2. Add a new abstraction layer — A new abstraction layer may hide the implementation details that leaked, however, it makes the system more complex. Be careful in this solution.
3. Accept — If there is nothing you can do with abstraction leak or it’s too costly then acceptance is the right choice. Remember about the Law of Leaky Abstractions.

Final notes

We see leaky abstractions every day in life and software. That’s the reason why we should be aware of them. Even though they are widespread we should try to create systems in a way that minimizes leakiness. It’s a difficult skill, but worth mastering in order to write a good quality code.