Abstraction in Object Oriented Programming

What is abstraction, within the paradigm of Object Oriented Programming. In what situations should we apply the concept of abstraction in our programs.

Abstraction is a real world term that we can apply as we understand it in the world of Object Oriented Programming. Something abstract is something that is in the universe of ideas, thoughts, but that cannot be materialized into something material, that can be touched.

Well, an abstract class is one on which we cannot create concrete specimens, in OOP jargon it is one on which we cannot instantiate objects. Now, what is the reason for the existence of abstract classes? Or put another way, why would I ever need to declare a class as abstract? In which cases should we apply them? This is all we intend to explain in this article.

Abstraction in the real world

Object-oriented programming we know that, in some way, tries to “model” the elements of the real world. In the world we live in, there is a universe of objects that collaborate with each other to perform system tasks. Taken to the programming environment, we must also program a series of classes from which objects can be instantiated that collaborate with each other to solve problems. If we assume this, in view of the situations that occur in the real world, we will be able to understand the abstraction.

When we studied the concept of we saw that with it we could define classification hierarchies: animals and depending on these we have mammals, vertebrates, invertebrates. Within mammals we have cows, dogs…

Animal can be from an ant to a dolphin or a human. In our brain the concept of animal is something generic that encompasses all animals: “living beings of a “kingdom” of existence.” If you define animal you have to use very generic words that cover all possible animals that may exist in the world. Therefore you cannot say which animals are those that are born from eggs, or after a period of gestation in the placenta.

What I want to get at is that the animal implies an abstraction of certain aspects. If we define it with words, we cannot go into much detail, because there are many different animals with very different characteristics. There are characteristics that remain in the air and cannot be fully defined when we think of the concept of a “generic” animal.

Finally, in the real world is there an “animal” as such? No, there isn’t even a “mammal”. What we have are specimens of “dog” or “cow”, “ant”, “crocodile”, “sparrow” but not “animal” in general. It is true that a dog is an animal, but the final concept, the specimen, is of a dog and not an animal.

Therefore “animal”, in terms of common language, we can say that it is a generic concept, but not a concretion. In terms of OOP we say that it is an abstract concept, which we will implement through an abstract class. We won’t instantiate animals as such in the world, but we will instantiate specimens of a particular type of animal.

In animals there are properties and methods that can be common to all animals in general. The animals may have a name or an age, certain dimensions or may carry out actions such as dying. What should be clear to us is that we should not be able to instantiate an animal as such. How is a specific animal born? How is it fed? To answer those questions we need to have more concrete specimens. I do know how an ant or a sparrow is born or how it feeds, but I cannot know it about a generic animal, because it can do it in many different ways.

We will continue working to explain these concepts, but for now we understand that “animal” is an abstract class, but “ant”, “dog” or “sparrow” would not be abstract classes, which we could instantiate.

inheritance and abstraction

If we understand the concept of inheritance we can better understand the abstraction and how it is implemented.

Remember our example: I have animals. We have agreed that I cannot have a specific animal instantiated on a system. If anything I will have instances of dogs, grasshoppers or lizards. Well, in inheritance schemes this case can arise very regularly.

In the “animal” class I can have certain properties and actions implemented. For example, all animals can have a name, or an age (either seconds, days, or years of age). It is also possible that you can define various actions at once for all the animals in a hereditary hierarchy, for example, the action of dying, since we all die the same (we simply cease to exist, although here depending on the beliefs of each one this may be debatable).

Although my system can’t create animals as such, having those issues defined for all animals is useful for me so I don’t have to program them again in all types of animals that may exist. I’ll just inherit them into the child classes, so they’ll be there without having to reprogram all that common stuff.

However, there are things about animals that I will not be able to implement yet. Attributes such as the number of legs, the range of vision, will be implemented in the future in the types of animals that need them, but let’s look at the actions or methods. For example, birth, feeding, etc. I don’t know how an animal is going to be born, but I know that all animals in the world are born in some way (some are born from eggs, others were in the belly of females and are born as a result of childbirth, etc.)

In these cases it can be useful to define as abstract methods in the “animal” class those methods that will be present in all animals, even if we are not able to implement them yet.

public abstract function born();

This means that all the animals in the world will inherit an abstract method called birth. In the concrete classes that inherit from animal and where we already know how such an animal is born, for example, the chicken, we can implement this method, so that it is no longer abstract.

public function hatch(){ //the egg is broken and the chick is hatched, which will later become a beautiful hen }

So far we know that there are classes that have abstract methods, which we are not able to implement yet, and classes in which abstract methods are inherited and in which we will be able to implement them.

We’ll understand the utility of this better in a few moments, when discussing polymorphism, but for now we need to be able to digest these more formal definitions:

“An abstract class is one in which there are defined abstract methods, on which we cannot instantiate objects” In addition, in an inheritance scheme, “If we inherit abstract methods from an abstract class, neither can we instantiate objects from the child classes and will have to be defined as abstract unless we implement each and every method that was declared as abstract in the parent class.”

Polymorphism and abstraction

I think if you don’t look closely at abstraction through the prism of polymorphism you can’t really understand the true utility of making classes abstract. But before going any further, remember what the .

When we talk about polymorphism we explain that it is a relaxation of the type system by which we were able to accept objects of one type and all child classes. For example, I have the class “PoligonoRegular”. I know that regular polygons I will want to know their area, but to know their area I need to know the number of sides they have. So the “RegularPolygon” class will have an abstract method “giveArea()”. Then, by defining the class “square”, or the “pentagon”, etc. we will be able to implement such a method, with which it will cease to be abstract. We have “Students from a University”, you will want to enroll students in universities, but depending on the type of student, enrollment is different, since it is not the same to enroll a student with a scholarship, or a large family, than a normal one. So in the “student” class I will have an abstract method called “matriculate()” that I can fully define when I implement the child classes.

Now think about this. Thanks to the abstract methods “dameArea()” and “matriculate()” being defined in the parent classes, one thing is clear to me: when I work with elements of the “PolygonRegular” class, I know that all the regular polygons that can be received I can ask them to give me back their area. I also know that I can ask all students to enroll in a university.

Therein lies the power of polymorphism, receiving an object that belongs to a classification hierarchy and knowing that I can ask it for certain things. Perhaps those behaviors could not be implemented in the parent class, because we did not know the necessary code for it, but at least it was declared that they would be able to be implemented in the future in child classes. This allows me, in a polymorphism scheme, to be sure that all the objects it receives can respond to certain actions, since in the child classes they will necessarily have been defined (if they are not defined, the classes should be declared as abstract and in that case It is impossible for them to send me objects of that class).

It is true that the concept can stay a bit in “abstraction” but when you practice a bit you will realize the essence of abstract classes and you will understand how useful and necessary it is to declare abstract methods in order to implement polymorphism. For now it is all about this concept, we hope that this text has been of some use to you. Of course, comments are appreciated.