object orientation – What is abstraction?

Question:

Across the web and also here on Stack, sometimes people talk about "abstraction" when it comes to software architecture/engineering and object orientation, mainly.

  • What is such an "abstraction"?
  • Why is she important?
  • How to get it in practice?

Answer:

Abstraction in information technology derives its meaning from the same concept in philosophy , which is "isolating an element from the exclusion of others". Its use is very similar to that done in math – instead of solving a problem for a very specific domain (eg I had four oranges and I ate two, how many do I have?) turn that problem into a more general problem (eg x = 4 - 2 ) and solve that problem by applying the resolution back to the original problem.

Giving a concrete example, how is a summation implemented?

var resultado = 0;
for ( var i = 0 ; i < array.length ; i++ )
    resultado += array[i];

And how to implement a product?

var resultado = 1;
for ( var i = 0 ; i < array.length ; i++ )
    resultado *= array[i];

Note that there are potentially N problems of the same format: you start with an initial value, apply an operation involving that value and an input element, the result of it combined with the next element, etc., until you reach the final result. By abstracting the problem in this way (ie isolating the common characteristics, parameterizing the specific ones) it is possible to arrive at a more general solution :

function reduce(array, fn, valorInicial) {
    var resultado = valorInicial;
    for ( var i = 0 ; i < array.length ; i++ )
        resultado = fn(resultado, array[i]);
    return resultado;
}

var somatorio = reduce([1,2,3,4,5], function(a,b) { return a + b; }, 0);
var produtorio = reduce([1,2,3,4,5], function(a,b) { return a * b; }, 1);

Another more common example in everyday life is the use of types and subtypes, and the creation of "generic" functions that act on multiple types. Instead of implementing a specific solution for a data type, one that serves several different types is implemented, thus avoiding code duplication.

Why this is important should be evident. How to get it in practice, there is already a matter of mathematical reasoning: trying to see similarities among the various concepts we deal with, describing this similarity in the form of a new concept (more general, or more abstract) and – according to the resources offered by your platform of choice – to develop solutions aimed at this new concept, so that they are easily reusable for more specific concepts.

Of course, much of this work has already been done by others, so the more knowledge you have – the more contact with other people's work involving abstraction – the easier it is for you to identify in practice when an abstraction applies to you, so that develop/reuse solutions accordingly. (Do as I say, don't do as I do: study math!)

Abstraction Layers

Finally, not directly part of the question but rather related, is the concept of "abstraction layers": often to solve a problem "at a high level" it is desirable to be able to ignore the "low level" details. For example, by typing "create a window" (ex.: new JFrame() ) you ignore all the work the computer has to draw the geometric shapes that make up this window, the handling of input (keyboard, mouse) on that window , etc. You're reasoning at a high level, and having to think about all these details would only get in your way.

On the other hand, whoever creates a library to implement a graphical interface does so in a very generic way, without worrying exactly what it will be used for (not how it will be used, this is part of the API, but the specific windows that will be used created). At the same time, at this stage, it is ignored how the computer will draw pixels on the screen, how the main memory will interact with the video card, etc. This is the work of those who create graphic libraries (such as OpenGL and DirectX).

Programmers who focus on end-user solutions are often at the highest level of abstraction (ie using the tools available to meet a real-world need), but they don't always have the tools at the best possible level. So if you find that you are (or are) repeating yourself too much in building a system, consider that it might be interesting to abstract a little of the problem you are dealing with – creating solutions for that abstraction, and then applying them to the real problem. This is using abstraction in practice.

Scroll to Top