Skip to content


stereobooster on January 06, 2019

Developers talk about abstractions all the time. For example: The purpose of abstraction is not to be vague, but to create a new semantic level i... [Read Full]
markdown guide

Here's my simple definition of "abstraction":

Abstraction is reuse.

Reuse is abstraction.

OK, they're equivalent. But what does "reuse" mean ?

Reuse means re...use.

So the process of abstraction means the process of creating something reusable !


I assume you are talking about reuse through the introduction of new entities rather than copy-paste, right? But the process of the introduction a new thing is more about symbolic thinking (the new thing is a symbol). It can be a process of abstraction (removal of details by hiding implementation) or not. If we will call all cases of reuse an abstraction it can get even more confusing.


Even if you successfully remove all details / hide implementation, it's not an abstraction if it's un-reusable (per my definition)

Well, people do not always build abstraction for reuse, sometimes they do it for simplification. Example when people introduce a lot of small functions with concise names (clearly communicating the purpose of each) and then construct final thing out of it. And they can use those functions only once (e.g. no reuse). This can be referred to as an abstraction.

I got you, but i just want to be more precise about terminology here.
Mine is more about goal-oriented definition.

In your case, i would call it just a refactoring, or simplification.

The Abstraction i mean is, in real world projects, we want to avoid copy-pasting, or DRY, that's why we want to "abstract" those repetitive pieces into only 1 piece.

Or, put more clearly, if you find yourself duplicate your code in two places that're almost the same, "abstract" it !

I'm thinking out loud.

On the other side, it can be interpreted following way: building software is building understanding - software is precise and executable knowledge. In this case, abstraction is "classical" cognitive trick to manage complexity and building knowledge. Ultimately nobody builds software for code, people build it to achieve something and software doesn't work in a vacuum it is also expecting some knowledge from the users. And in this case, repetition of pieces of code is not a big deal, but recognition of the same concepts (abstracts) in different places is important.

Just want to remind that ours (developers) pursuit for DRYness bites us often and it is not ultimate purpose to build DRYest code ever. The ultimate purpose is to make it work, make it right, make it fast. This is what Sandi Metz talks about:

Prefer duplication over the wrong abstraction.

The fact that you made the wrong "abstraction" doesn't invalidate my definition on Abstraction. ;)

For clarity: I didn't try to invalidate your definition. It was more thoughts out loud.

Speaking of terminology...

we want to avoid copy-pasting, or DRY, that's why we want to "abstract" those repetitive pieces into only 1 piece

In my world that's called "refactoring". You can stay in the same abstraction layer while refactoring, e.g. you build a simulation like The Sims and have objects like Cars as well as Trucks with their own constructor. When refactoring you find duplicate code in these constructors and decide to apply the DRY principle. This might result in a VehicleFactory, which is a generalisation, but not an abstraction. You're still in the object/terminology world of your Sims and you might also find a NatureFactory that will create Trees and Flowers in your Sims' world. All these things are in the same abstraction layer. Going the ladder one layer up, you might find your VehicleFactory and NatureFactory being called in initialiseGame. You know that you're in a different abstraction layer when you've got a different vocabulary. The Sims know what a Tree is and what a Car is, because these are the objects in their world. But a Sim wouldn't understand initialiseGame, because that's the vocabulary of the player.

Hmm. We might be speaking of an “abstraction” as a either concept or as a component of a software system. In each case, reuse is a useful property of an abstraction and a good reason to keep it. However, I might create an abstraction to be used only once and still be justified in that, as it might allow me to better organize my thoughts. I could also likely reuse things that are not abstractions, such as a doorknob. (Though one could argue that my using the word doorknob to describe a meaningful group of atoms is nothing if not an abstraction... ?)

Therefore, in my view, reuse is a benefit of abstraction but not it’s definition.

So you consider generalization and abstraction as different things? How would you define both?


I go along with Dijkstra ("to create a new semantic level in which one can be absolutely precise"). IMHO re-usability is just a (good) side-effect of abstractions.

Do you agree that the uppermost abstraction layer should represent (or use the language of) the business domain? I think this is a good approach, which comes easy when designing top-down.


I admit that using Mondrian’s art as a leading picture to the writing on “abstractions in CS” is a best trolling of 2019 so far :)

I will definitely use Victory Boogie Woogie as the preface to my upcoming talk on microservices.


I don't see any trolling here.

Abstraction in art is essentially the same process as I described for CS. It is about removing details.

Image from "Understanding Comics: The Invisible Art" by Scott McCloud.


Abstraction IMSO is more about building hyperonyms out of hyponyms.

Like you have cats and dogs and you find out a common mammal noun.

Not about everything is a pixel, line, and their intersection. See e.g. Kandinsky.

Say that we ignore certain aspects of the hyponyms, such as all the cat-specific and dog-specific qualities, when creating the hyperonym. If there were no such qualities to ignore, we could just say we had two dogs.

So the idea that some detail is removed is intrinsic to the process of abstracting when using Aleksei’s idea of what abstraction is.


We move from “ears that look like this” to “ears that look NOT like this.”

The common nature that is still there is essential.


Abstract art by European modernists like Joseph Albers and Piet Mondrian we're insanely mathy and rule based. Basically an exercise in seeing how far you could divide and routinely paint a grid. I wouldn't want to be them.

Abstract expressionism like Jackson Pollock was all about expressing what he thought was freedom, chance and randomness.
Both are dubbed "abstract" but operate on different implementations lol.

Living artist with no painting skills just has to pitch in. Comment irrelevant but tangentially relevant, on some abstract plane.


Abstraction is an artifact of the process of details removal- yes.

Abstraction is also an artifact of the process of pattern recognition, or the surfacing of meaningful groupings.

One defines in terms of what it’s removes and one defines in terms of what it surfaces.

What is the artifact, by the way? Just a useful name for something.

It seems similar to how neuronal clustering fuses groupings of information together into neighborhoods, highways, maps, etc.

Thank you for writing about this stuff stereobooster! I’m glad you’re out here focusing on the abstract stuff.


Thank you for this overview of computational (?) abstraction-thinking. I'm halfway through and will return to add my thoughts. I enjoyed your tracing of the etymology. 🤔 (thinking abstract thoughts.)

code of conduct - report abuse