51–60 of 240 posts
I forget which programming talk I watched which pointed this out, but one extremely common example of this in Java is recreating subsets of the Collections API. I've done this before, heck even the Java standard library is guilty of this problem. When a class has a full set of get/put/has/remove methods, it is often not actually hiding the complexity of its component data structures.
The best way to achieve a good abstraction is to recall what the word meant before computer science: namely, something closer to generalization . In computing, we emphasize the communicational (i.e. interface) aspects of our code, and, in this respect, tend to focus on an "abstraction"'s role in hiding information. But a good abstraction does more than simply hide detail, it generalizes particulars into a new kind of…
Data = representations = abstractions
This article is so fundamentally lost that it forgets what computers are for.
Computers exist to implement abstractions.
Pretty easy to give generic advice without examples. “Write more tests, but not too many” “Use good abstractions where appropriate?” “The next time you reach for an abstraction, ask yourself: Is this truly simplifying the system? Or is it just another layer of indirection?” It’s easy to create a strawman here (the FactoryAdaptorMapper or whatever) but in reality this kind of generic advice doesn’t help anyone. Of cou…
A principle takes skill the apply, but it's still worth stating and pondering.
The best way to achieve a good abstraction is to recall what the word meant before computer science: namely, something closer to generalization . In computing, we emphasize the communicational (i.e. interface) aspects of our code, and, in this respect, tend to focus on an "abstraction"'s role in hiding information. But a good abstraction does more than simply hide detail, it generalizes particulars into a new kind of…
Computers are to manipulate data. Data = representations = abstractions This article is so fundamentally lost that it forgets what computers are for. Computers exist to implement abstractions.
Earlier quoted context omitted.
Computers are to manipulate data. Data = representations = abstractions This article is so fundamentally lost that it forgets what computers are for. Computers exist to implement abstractions.
Did you even read it?
Earlier quoted context omitted.
In short: good abstractions simplify by centralizing operational logic. But it's not until a certain scale where that option is more efficient from bespoke implementations.
A heuristic we use at work is to not introduce an abstraction layer until there are at least two different implementations required. That is if you think you'll probably need multiple implications, delay introducing an abstraction until you actually do. Also, there are different ways of providing abstraction. Perhaps you don't need to abstract the entire implementation but, as an example, rather change one parameter…
- not doing extra work now if it's not necessary yet and if it's as cheap to do later
- delaying building a thing till you know what that thing should be
The best way to achieve a good abstraction is to recall what the word meant before computer science: namely, something closer to generalization . In computing, we emphasize the communicational (i.e. interface) aspects of our code, and, in this respect, tend to focus on an "abstraction"'s role in hiding information. But a good abstraction does more than simply hide detail, it generalizes particulars into a new kind of…
Abstraction not only hide details, but also add semantic value.
Earlier quoted context omitted.
Did you even read it?
Unfortunately, I did. It is an attempt to approach complexity, cognitive load and high entropy in code, jumping to conclusions prematurely while suggesting a solution that is worse than the problem.
Abstraction hides detail, but at what coat? A network close call at a high level closes a network socket. But at the tcp level there's a difference between close and reset. Which do you want? Your api has removed that choice from you, and if you look you will have no idea if rhe close api does a close or a reset. Is the difference important? If depends. If you have a bunch of half open sockets and run out of file des…
If you are doing a „TCP application” of course it makes no sense to abstract the TCP layer. Is not about cost. Now if you have an application that has to communicate somehow with other system, and you want to not depend on specific protocols, then the communication part should abstract away that part.
How to deal with your example? Well, if you can say “I will always want X, you can make a configuration option “TCP.close” or “TCP.reset”. If “it depends” then you have to build the logic for the selection in the abstraction layer, which keeps hidden.