I found this nice post by Azubuko Obele on value of abstraction. Abstraction is such a non-material concept that it can provide multiple values depending on your approach towards it. The article also points to another post on difference between indirection and abstraction.
I got a mixed feeling after reading both the posts. There were too many terms flying in the air to relate them to each other - abstraction, indirection, simplification, data hiding, generalization. This probably is a proof of different values that one can obtain out of abstraction. However, it is difficult to then understand why should abstraction be used, and when! Abstraction is not just a computer science asset, its origins can be found in mathematics and philosophy. So, lets make the issue more complex and introduce another term - Specification.
Abstraction And Specification
My understanding tilts me towards using abstraction for specification - for separating what from how. A lot of times this can result into grouping common attributes or behavior which can lead to generalization. A lot of times this can lead to exclusion of hiding of details that can avoid information overload. A lot of times this can bring out the real essence of issue at hand leading to simplification for understanding.
Being able to differentiate between what and how, and work with them separately gives me two benefits. One is that I can specify (or specify constraints) without thinking of how the specifications will be carried out. This separation then lets me or someone else use multiple hows for a single what, or multiple implementations for the specification. There is more freedom in selecting the right implementation which can be affected by environmental factors. Logically, I first try to find out what something/someone does before trying to find out how something/someone does it. I might or might not need to learn how. Not needing to learn how is in fact good, I can skip unnecessary (for me) information and I can focus on what I need to know.
Abstraction And Simplification
More often than not, being able to separate what and how simplifies the problem you are looking at. However, this simplification is only for understanding, it actually does not solve the problem for you.
One example is (and feel free to find holes in this if you do not agree) the e-banking system. In the physical banking, for lack of better words, my signature is used for identification and authorization. This is so because I do the same signature for every transaction. When I want to automate this, I will create a difficult system to use if I have to authorize the same way. Here, abstraction can help me to specify that the task is to identify and authorize. Once this is specified now I can use signatures for physical banking, username/password/transaction password for e-banking, cards/pin numbers for ATM or phone banking. By separating the specification now it can be implemented in multiple ways, and it simplifies the problem of what we are trying to do here. However, it does not simplify the problem of implementing the e-banking system.
Abstraction, Encapsulation And Indirection
Abstraction is not data-hiding, it can be considered as a byproduct of separating what and how. Encapsulation is data hiding, but hiding only the unnecessary data. The user needs to know only the specifications to be able to use something. Which is where the significance of interface comes in.
In my opinion indirection is one of the ways of implementing abstraction. Indirection actually gives you loose coupling. Loose coupling gives you freedom to change, with minimal impact on the other parties talking to you. But indirection does not mean abstraction.
Abstraction And Why
This is something that probably I repeat in all my thoughts on abstraction. Asking the question Why is my approach of identifying abstraction. Of identifying the purpose, the intent, the goal and separating it from the means. Using a series of Why questions I typically am able to follow a single thread of reasons to reach the final what, the top abstraction. This is required because when we talk to users the purpose is implicit in the actions. So implicit that sometimes they do not realise it exclusively. I have not been able to abstract without asking the question Why. Whether I am doing modelling, designing or analyzing an existing system.
Abstraction can be discussed in multiple contexts and can be used in multiple ways to achieve many of its advantages. The basic one I see is the ability to specify the what without involving the how. This makes all the difference.
