Abstractions are a central concept in software development. In my opinion, it is the most important concept to master, since it underpins everything that we do. Dependency injection would be very weak without it. Polymorphism wouldn’t exist. Unit testing would be borderline impossible. The software models themselves that we build are abstractions of the problem we are trying to solve.
Throughout my time as a software developer, I have discovered that abstractions are something that some developers have quite a bit of trouble with, especially junior developers. That’s because they are usually viewed solely as a technical thing. Interfaces and abstract classes are simply tools of that specific programming language. They didn’t actually represent anything other than a way of sending different kinds of classes into the same method. In this article, I’ll try to explain what abstractions are without trying to relate it to software development at all.
Abstractions in real life
Even though you might not realize it, abstractions are an omnipresent part of the human experience. Every time we communicate with each other, we use abstractions. When I tell you I had pizza yesterday, I am abstracting the filling away, since I don’t think that’s an important detail. I might have – I had this delicious kebab pizza, with red onions and just a bit of sweet chilli sauce. Or maybe, instead of saying; I went to work yesterday, I might say that I biked to work. This is exactly what abstractions are. They help bring into focus the important parts of “something” by either hiding unimportant details away or shining a light on the critical ones. Let’s try a little experiment. Join me if you can, you only need a pen and some paper.
Alright, let’s give it a go! First, I want you to draw a bus.
Cool, now I want you to draw a pickup truck:
Next, try drawing a cargo truck.
Awesome! Now finally, I want you to draw a vehicle.
Wait, what? What do you mean you can’t draw a vehicle? You see them every day, don’t you? So you drew something anyways? But… That’s a car… I think? You aren’t very good at drawing, are you?
You see, while the concept of vehicles does exist, there is exists no such thing as a concrete vehicle. The term vehicle is something that we use to describe a class of things which have a set of wheels, a motor, the ability to accelerate or a brake, among many other things. Now let’s get back to that car you just drew.
Now, is that really a car? Looks more like one of those sports cars. What kind though – is it a Dodge viper, a Corvette or an entirely different brand?
Did you notice that what was before an acceptable abstraction, no longer suits our needs? I’m talking about even more specific versions of a sports car by talking about the brand of the car. If we were talking about going to fetch some food, then “We can take my car to the grocery store” would suffice. But if we were talking about a car you were looking to buy, I would like as many details as possible! What brand, model and maybe even year are you looking at? Abstractions change depending on the context they are used in.
Different kinds of abstractions
There are 3 main kinds of abstractions: Specializations, generalizations and contracts. Generalizations of a specific thing or concept lack the finer details of that thing or concept. A video game console is a generalization of a PlayStation, just as a vehicle is a generalization of a car. A specialization, on the other hand, is much more specific. A tiger is a specialization of an animal, a Chevy is a specialization of a pickup truck.
Contracts are a bit different. While technically, contracts are just generalizations, practically they are used in very different contexts. Contracts state that whatever is bound by it will fulfil its obligations. While the wiki page describing contracts does so in the context of law, it’s pretty comparable to what we are trying to use them for. They are used exclusively to hide details about whatever is bound to that contract. Think of power consumers:
There’s a contract here, that power will be provided in a specific voltage and current. You can choose to consume it as you see fit. Where that power is coming from doesn’t really concern us in this context. Remember that there are loads of different power adapters in the world. That’s usually because different countries provide power in different ways. That is done by delivering higher or lower voltages and maybe even a different current. By using an appliance with an incorrect power source, you usually end up breaking it.
Now there is something else that is a bit more interesting that can fulfil contracts: trades and services. Any doctor will provide a diagnosis given a symptom report. A tourist agency will deliver an itinerary after you give them a list of places you wish to visit.
It’s important to note that different doctors might give a different diagnosis, depending on their speciality. A paediatrician and a physician might give a totally different diagnosis, given the same symptom report. One, or maybe even both, might not even be able to help you. Worst-case scenario, they might even give you a wrong diagnosis! That is due to the fact that a doctor contract is a really general one. Well, there is actually something we can do about it!
Abstracting contracts
Well, it turns out that we can apply the concept of abstraction to contracts themselves! We can either generalize or specialize a contract as we see fit. Going back to the doctor example, while not all doctors might be obliged to give you a diagnosis based on your specific symptoms, they can refer you to a practice that can. So that might be one of the few obligations ALL doctors must fulfil. We can try specializing the contract, then we might be able to get some help. For example, a neurologist will be able to diagnose you based on a list of symptoms on the nervous system. An ophthalmologist will be able to diagnose you based on a list of symptoms on the eyes. A general practitioner might be able to give you a general diagnosis based on a general list of symptoms.
You might have noticed that the symptoms themselves are abstractions. Symptoms on the eyes is a specific kind of symptom. You might also be able to argue that the diagnosis itself could be an abstraction. Just like this example, things are very rarely cut and dried. I might be choosing some terrible abstractions, but in the context of explaining what abstractions are, I think they work okay.
Abstractions themselves can also fulfil contracts. If we for example said that all humans could fulfill the doctor contract, then ALL humans are doctors by definition. If we instead said that only educated humans that have been through medical school are doctors, then only that specialization of humans can fulfill that contract.
That last example got kind of murky, didn’t it? Isn’t educated a characteristic of a human, and not a kind of human? What about gender, is that a specialization, or a characteristic? This is one of the great challenges when trying to describe objects and concepts. Depending on the context and our needs, we might chose to describe something as an abstraction or vice-versa.
I hope I was able to give you a general idea of the concept of abstraction, and how it relates to the real world. Next time, I’ll be explaining abstractions in a technical frame. I hope you enjoyed reading this article as much as I enjoyed writing it!
2 thoughts on “The concept of abstraction, no code allowed”