Hot answers tagged abstraction
88
If you find it difficult to read 0s and 1s below, scroll to the bottom of the post and hover over the empty looking "spoiler" gray box.
01010100 01101000 01100101 00100000 01110010 01100101 01100001 01110011 01101111 01101110 00100000 01110100 01101000 01100001 01110100 00100000 01110000 01110010 01101111 01100111 01110010 01100001 01101101 01101101 ...
31
I think you have some misconceptions about the history of computing.
The first abstraction (in 1936) was, in fact, Alonzo Church's Lambda Calculus, which is the foundation for the concept of high-order functions and all of the functional languages that followed. It directly inspired Lisp (the second oldest high-level programming language, created in 1959), ...
25
Which to listen to and how often?
Never abstract until you must.
In Java, for example, you must use interfaces. They're an abstraction.
In Python you don't have interfaces, you have Duck Typing, and you don't need towering levels of abstraction. So you just don't.
What is your strategy for this?
Don't abstract until you've written it three ...
24
The answer to "Can you define what a programming abstraction is more or less mathematically?" is "no." Abstraction is not a mathematical concept. It would be like asking someone to explain the color of a lemon mathematically.
If you want a good definition though: abstraction is the process of moving from a specific idea to a more general one. For example, ...
24
It seems to me that you misunderstand abstractions and code reuse.
The whole software development industry is built on abstractions. Just because not using them, i.e. avoiding using frameworks, libraries and in general code which is not written in-house, would increase the cost you need to produce a piece of software by hundred, thousand, probably even ...
22
Data types exist to give bits some "shape." Without that shape, bits would be just so many ones and zeroes.
Everything has a shape. Imagine asking someone to look at your raw bits, instead of the picture these bit embody in the JPG format. Imagine if your arrangement of bits that comprises a picture were different from everyone else's. You would have to ...
19
I categorically disagree with most of the answers.
This is my answer:
Given two sets G and H, a Galois connection (alpha, beta) can be defined between them, and one can be said to be a concretization of the other; reverse the connection, and one is an abstraction of the other. The functions are a concretization function and an abstraction function.
...
17
Ah, YAGNI. The most abused concept of programming.
There's a difference between making your code generic and doing extra work. Should you spend extra time to make your code loosely coupled and easily adapted to do other things? Absolutely. Should you spend time implementing unneeded functionality? No. Should you spend time making your code work with ...
17
Because you need to know the encoding.
Let me put it this way. An integer is a sequence of ones and zeroes- but you don't know what value that integer is, unless you know in advance it's two's complement or whatever. If you have a pointer to a sequence of bits, how many of those bits makes the integer you're looking at? If you don't know, how can you ...
15
Frameworks can be tricky indeed. Problems can easily arise when a framework is too "opinionated", i.e. when it really prefers one particular style of application and all parts are geared towards supporting this particular style.
For instance, if the framework completely abstracts the authentication process of a user by allowing you to just add one ...
14
Good uses for wrapper functions:
Hiding the complexity of a horribly complex or unsafe, low-level API, for example, the Win32 API. However, your wrapper must actually reduce complexity and/or increase safety for the common cases.
Making something cross-platform when you are writing a generic library or have a good reason to believe it needs to be ...
14
The keyword for thinking about these things is abstraction.
Abstraction just means deliberately ignoring the details of a system so that you can think about it as a single, indivisible component when assembling a larger system out of many subsystems. It is unimaginably powerful - writing a modern application program while considering the details of memory ...
12
Yes, every programmer should learn new languages, and particularly languages that uses a different programming paradigm e.g. functional programming or concurrency oriented programming.
Even if you will not use the language, you will be a better programmer in the language you use by learning different concepts and see alternative solutions.
There is an ...
12
A shim is typically something written specifically to maintain backwards compatibility. For example, if you have two versions of an API, version 1 and version 2, then rather than maintaining version 1 independently of version 2, you might write a shim that intercepts calls to version 1 of the API, translates the parameters to what version 2 requires, and ...
12
Dependency Injection and DDD are two disjoint concepts. Doing Dependency Injection does not require to do DDD nor does DDD require Dependency Injection.
A lot of DDD projects fail because they pick the patterns but neglect the process behind DDD. They do not take the time to extract business rules. They do not concentrate on the domain model and on careful ...
12
Yes, you're right - in general Java requires a lot of ceremony for surprisingly simple situations*. The obvious advantage is that you see each step of the way to your goal, so you have more control. Network communications are done by wrapping messages inside envelopes, so you are exposed to this layering -- your library already hides many layers for you, but ...
11
Abstraction is more focus on What and less on How. Or you can say, know only the things you need to, and just trust the provider for all other services. It sometimes even hides the identity of the service provider.
For example, this site provides a system for asking questions and answering them. Almost everyone here knows what are the procedures for asking, ...
11
It can, but likely won't lead to a problem.
It's just economics. If the vast majority of people lose the ability to understand the underlying architecture, and there is still a huge NEED to understand the underlying architecture, then the ones who do will have jobs and get paid more, while those who don't will only have jobs where that is not needed (and ...
11
Sometimes a change is large enough that you have to design a migration path. Even if the start and end points are well designed, you often can't just switch cold turkey. A lot of otherwise good designers fail to design good migration paths.
This is why I think every programmer should do a stint writing software for 24/7 production environments. There's ...
10
A syllogism:
Generality is expensive.
You are spending other people's money.
Therefore the expense of generality must be justified to the stakeholders.
Ask yourself if you are really solving the more general problem in order to save the stakeholders money later on, or if you just find it an intellectual challenge to make an unnecessarily general ...
10
That means that every time I'm going to write a class that isn't a simple data structure, which is most classes, I should write an interface or abstract class first, right?
Yup.
Is it really worthwhile to go that far in defining abstract classes an interfaces?
No, but you should err toward more interfaces than less.
Can anyone explain why in ...
9
I think so. It's a trend that has me worried. No abstraction is perfect; if there was a perfect way to simplify any complex problem, it would replace the original very quickly. (That's happened in the past, occasionally with computers, and a lot more frequently in other fields that don't worry as much about backwards compatibility as we do, such as ...
9
I'd recommend you to read the Big Ball of Mud essay.
Basically the point that the design tends to deteriorate as you progress with development and you have to dedicate work towards containing the complexity. The complexity itself can't be eliminated, only contained, because it's inherent in the problem you are trying to solve.
This leads to the main ...
9
The point of a factory is to hide the fact that you may get objects from slightly different classes. Therefore, if some of these objects need certain data and others don't...
Either they aren't similar enough to be produced by the same factory. Then you need to have more than one factory and make the decision way earlier than you are currently doing.
Or ...
8
I've got no problem with using high-level abstractions, with two caveats:
Any abstraction that you can't get underneath when necessary is evil, because it will occasionally be necessary. Avoid these.
Don't ever use any abstraction without a solid understanding of what's really going on under the hood. Not doing this will frequently cause performance ...
8
I think the abstract methods are the better choice. If the implementation of these properties is not something you want the sub-classes to worry about, you may even want the base class to be responsible for it i.e. use private fields in the base
class with public accessors and protected mutators:
public class SuperBaseClass {
private int numberOne;
...
8
The fundamental idea in DI is simply to push dependencies into objects, rather than letting them pull dependencies from outside. This was also called "inversion of control" earlier. This allows one to control dependencies much better, and - last but not least - to write code which is easy to unit test.
DI frameworks only build on top of this idea, and ...
7
An abstraction is just the programming version of a theorem.
You have a formal system, you propose a thought about that system. You do a proof of it, and if it works out, then you have a theorem. Knowing that your theorem holds, you can then use it in further proofs about the system. Primitives provided by the system (like if statements and int value ...
7
Your question reminded me of a point Paul Graham makes in On Lisp:
If people complain that using utilities makes your code hard to read, they
probably don’t realize what the code would look like if you hadn’t used them.
Bottom-up programming makes what would otherwise be a large program look
like a small, simple one. This can give the impression that the ...
7
My questions are: Would passing the thrown internal exception as the previous exception be leaking the abstraction? If not, would it be suitable to simply reuse the previous exception's message?
The answer is: "it depends".
Specifically, it depends on the exception, and what it means. In essence, rethrowing it means you are adding that to your ...
Only top voted, non community-wiki answers of a minimum length are eligible
