13
I was listening to a podcast and the term arose Leaky abstraction. The example given is something like this: A system uses a relational database and has a generic class for data access, at a given time that database is exchanged for a non-relational one, so that class can have Leaky abstraction
Related questions:
What is abstraction from a framework?
Note: I do not know if the term aportuguesado is correct
13
As the definition already existing there, abstraction is to hide details, is to generalize a solution where the mechanism is more hidden and give only a point of contact and a contract of how to communicate with that.
The leakage of abstraction is something that is not but should be hidden, that those who consume should not know or have to deal with and end up having to do it. So there is leakage when the consumer has to deal with things that could have been hidden from him without harm.
It’s really hard to do something that doesn’t leak. I always talk about how hard it is to create the right abstractions, or we leak it or we oversize it. The example of the question is one of the most common abstractions that we overelaborate. We create complications to have something abstract that never needs to be used in fact, the database never changes.
But it’s worse, who doesn’t know how to abstract correctly, and almost nobody does, tends to create a lot of problems. We see in codes here on the site people want to abstract the database, they don’t even know why they’re doing it, but they do it naively and create difficulties, introduce bugs trying to reproduce the concrete in the abstraction, only that whoever made the concrete knew what he was doing.
You think it can’t get any worse? If she doesn’t know how to do it well, she leaks specific abstractions, and some details end up not being abstracted, then you realize it was a bug, but as it was not correctly abstracted it is not possible to correct it without breaking everything that had written, and you have the worst of both worlds. In many cases do not abstract, despite being a complete leak, may be better than occasional unwanted leaks, but that you do not notice. A conscious leak can cause less harm.
It is common for leaks to appear in new versions. You realize that abstraction is inflexible and does not solve all the cases you imagined it would solve, then almost always the solution is to leak an abstraction to go over it.
Frameworks are abstractions. As they do not solve everything they end up having to let you go over their heads. So libraries tend to be more consistent. Frameworks are known to leak like crazy, because they propose to solve things they can’t without losing flexibility. People don’t even realize they’re creating leaks all the time, even their most basic things. Which is not a problem in itself, at least not one greater than it would cause if it eliminated the abstraction.
Trying not to leak can bring other problems. Stopping leaking can complicate the internal code of abstraction or even for consumption. More and more we see people so worried about it that they produce real aberrations.
One of the biggest shortcomings of programmers nowadays is not knowing how to abstract things, with this repeat a lot of code, leave room for error, and burden consumers with these codes, which is still a leak.
I won’t tell you what’s already in Joel’s article linked down below.
Exceptions are often leaking abstractions in many cases, as far as they are well used.
Manual memory management is a leak, the Garbage Collector is the right abstraction. But there are cases that it fails, there is leakage. You have to adopt certain code patterns to avoid breaks is a leak.
If compilers were really good they wouldn’t require us to know how to do a lot of things, especially for performance.
Having to convert a textual representation of the number into a number is a leak. We know that attempts to solve this have created aberrations in languages.
I liked the example given in response in the OS. The car is full of abstractions to be easy to drive, imagine you have to control the differential of the car in hand. A manual gearshift is an abstraction leak, you have to take care of a car operation mechanism that he should handle alone. Arrow is a necessity nowadays, but shouldn’t it be automatic when we start turning the wheel more strongly even if it is delayed? Was traction control a way to end an abstraction leak? Is just turning on a light indicating a problem not an abstraction leak? Or it shows nothing and you have to realize on your own?
Have you noticed that it’s debatable what leakage is or not? The steering wheel is not considered leakage because it is the minimum way to communicate with the car to say what it should do. But the concept can change because soon we will have cars where you say where you want to go and it takes you there without major worries, but today it is a purposeful leak to not complicate the whole and make the project unfeasible. Not being able to do different is no excuse to say that there was no leak, it’s just justification to accept it. And you realize that we can ignore a leak because we think there’s no other way to do it or that it’s not necessary to have an abstraction there?
Having to know how to use Git or SVN is an abstraction leak with the user. I should just know that I want to control versions, not the details of these tools. Imagine how many things you force your user to do that the system could handle alone in the code. Leaking abstraction on another level affects the user experience. Because you think people use the phone better (less my mom) than the computer?
Banks and other sectors are increasingly leaking abstractions from their services, one of the reasons they either reduce prices or increase their profits. And "smart" is the one who can only do the second by raising the charge on you.
Especially object-oriented that promises something difficult to deliver, because all abstractions lie. And the map is not the territory, has no way to reproduce the territory there.
All abstractions Lie -- including this one
I keep repeating that we have not mastered the problem enough to create good abstractions, something nailed to OOP. So we need to loosen things up so it’s easier to change later, and OOP complicates that. And so OOP goes better when we don’t reproduce the real world and we create our own abstractions. Even in GUI where OOP goes well, its abstractions are lousy, so much so that you can’t map the GUI well from one platform to another.
See the article by one of the creators of this site on the subject.
The "canonical" document on the subject was written by another of the creators of this site. At least it was he who warned everyone about the problem.
Stuff orthogonal are as important or more important than abstractions.
Simplicity eats abstraction at breakfast. When abstraction generates simplicity it is good, when this does not occur leaks exist or will arise. The complicated causes leakage.
I hope that analogies and examples outside programming help understand abstraction and its leakage.
Browser other questions tagged terminology software-engineering abstraction
You are not signed in. Login or sign up in order to post.
i) Very good example of the car; ii) I believe that the Analogies and examples outside the programming helped better if they were; iii) Until hearing the podcast and read that answer I would use the weird excuse of "if I want to change the bank it’s easier).
– Barbetta
@Barbetta and also does not stay, I think there is something about it here, although not directly.
– Maniero
yes, especially if the change is from relational to non-relational. I heard it so much that I never stopped to think and I made it true, and then there’s what I said, "the database never changes." I at least never saw changing kkkk
– Barbetta
Then it really screwed up. And then it leaks everywhere to be able to make at least work.
– Maniero