What is an abstraction?

Question

Web outside and also here in Stack, sometimes we talk about "abstraction" when the subject is architecture/engineering software and orientation to objects, mainly.

• What is this "abstraction"?
• Why is it important?
• How to get it in practice?

Answer 1

Abstraction in computer science has its meaning derived from the same concept in philosophy, which is to "isolate one element to the exclusion of others". Its use is very similar to that done in mathematics - rather than solving a problem for a very specific domain (e.g.: had four oranges and ate two, how many have I got? ) turn this problem into a more general problem (ex.: x = 4 - 2) and resolve that problem, applying the resolution back to the original problem.

Giving a concrete example, how to implement a sum?

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: starting with an initial value, applying an operation involving that value and an input element, the result of the same combined with the next element, etc., until reaching the final result. By abstracting the problem in this way (i.e. isolating common characteristics, parameterizing by specifics) one can 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 most common example in everyday life is the use of types and subtypes, and the creation of "generic" functions that act on various types. Instead of implementing a specific solution for a type of data, one is implemented that meets several different types, thus avoiding code duplicity.

Why this is important must be evident. How to achieve in practice, there is already a question of mathematical reasoning: try to see similarities among the various concepts with which we deal, describe this similarity in the form of a new concept (more general, or more abstract) and - depending on the resources offered by your platform of choice - develop solutions focused on this new concept, so that it can be easily reused by the most specific concepts.

Naturally, much of this work has already been done by others, so that the more knowledge you have - the more contact with third-party work involving abstraction - the more easily you will have to identify in practice when an abstraction applies to your case, in order to develop/reuse solutions to this effect. (Do what I say, don’t do what I do: study mathematics!)

Layers of Abstraction

Finally, not directly part of the question but rather related, there is the concept of "layers of abstraction": often to solve a problem "at a high level" is desirable if you can ignore the "low level" details. For example, when typing "create a window" (eg.: new JFrame()) you ignore all the work that the computer has to draw the geometric shapes that make up this window, the treatment of the input (keyboard, mouse) on this window, etc. You are reasoning at a high level, and having to think of these details would only get you into trouble.

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 (no as will be used, this is part of the API, but rather the specific windows that will be created). At the same time that in this phase ignores how the computer will draw the 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 solutions for the general end-user are at the highest abstraction level (i.e. using the tools available to meet a real-world need), but do not always have the tools at the best possible level. So if you notice that you are (or will) repeating yourself too much in the construction of a system, consider that it might be interesting to abstract a little bit the problem you are dealing with - creating solutions to this abstraction, and then applying them to the real problem. That’s using abstraction in practice.

Answer 2

• What is this "abstraction"? I have learned and have in my mind the following definition:

Abstraction for OO, is nothing more than you observe day-to-day behaviors and structures, and turn them into a computational language.

• Why is it important?

Because by using it wisely or in the right way, you will be able to create computational systems that are closer to the user’s expectations with less effort and more quality. In other words you will really manage to atenteder the user’s need.

• How to get it in practice?

Not to mention that this is an arduous process, and that few people master it with mastery, you will achieve it with much study, and practice at the same time. All right, it’s not that hard, but if more people dominated as they should, many systems would not be contracted in deplorable states as we see so easily today.

That’s my opinion, based on what I’ve learned about software engineering so far! , I tried to be brief and hope to have helped!

Valeuu! D

Answer 3

TL;DR

What is Abstraction?

Abstraction is the act of summarizing characteristics or similar actions shared between two or more objects.

Why is it important?

Because when done well it reinforces the paradigm of virtualizing the real world.

How to get it in practice?

Observing similar states and behaviors between two or more objects.

---

According to Wikipedia:

In Computer Science, abstraction is the process of separating specific ideas from working methods. Computational structures are defined by their meanings (semantics) while hiding details of how they work. Abstraction tries to factor details from a common pattern so programmers can work closer to human reality.

"But it’s such a dull drug!" - Tank, Matrix

Object Orientation does not have as one of the most basic objectives to represent the real world in a programmatic way? An object Door represents a door in the real world, with its characteristics (properties) and actions (methods).

And just as in the real world several things have similarities, whether of characteristics or actions. The difference is that not each other, after all if it were so we would open the car door and the refrigerator would be opened together.

Let’s continue with the example of the object Door. We will now enter an object Gate. Both are basically the same thing, has shared characteristics, shares in common, but one Gate has some things that a Door common does not have (remote control, maybe).

Without abstraction we would have:

class Porta {

    private $isOpen = FALSE;

    public function __construct() {}

    public function open() {

        $this -> isOpen = TRUE;
    }

    public function close() {

        $this -> isOpen = FALSE;
    }
}

class Portao {

    private $isOpen = FALSE;

    public function __construct() {}

    public function open() {

        $this -> isOpen = TRUE;
    }

    public function close() {

        $this -> isOpen = FALSE;
    }
}

Anything a Gate needed to open/close, for example, could be implemented in its own methods, but it would not eliminate the code Smell of repetition.

And if we repeat this again, again and again it’s time to abstract!

In our didactic scenario we can summarize so much to Door as to the Gate to:

• Have a physical structure that blocks or frees access to the inside/ outside (the door itself)
• Open and close

The first is a feature and the last two, actions. Our preliminary refactoring would be:

class Porta {

    protected $isOpen = FALSE;

    public function __construct() {}

    public function open() {

        $this -> isOpen = TRUE;
    }

    public function close() {

        $this -> isOpen = FALSE;
    }
}

class Portao extends Porta {}

Abstract to flag Door state, if opened or closed and opening and closing actions reducing objects.

Public actions are best characterized by Interfaces disregarded here