Benefits of Object Oriented Programming

What are the benefits that Object Oriented Programming brings us: Abstraction, Encapsulation, Modularity, Hierarchy.

We recently made a video of . The class was given by Luis Fernández and he clarified many details that we want to talk about now. It is about delving into several concepts that are basic to understand the benefits of Object Oriented Programming.

There are several concepts that we find present in the most modern programming languages, so it is no longer just about “objects” but about programming in general. New languages ​​with new paradigms do nothing more than provide us with tools so that we programmers can maximize the presence of the benefits that we are going to explain in this article. They are also the basis of the evolution of languages, which have marked the history of programming.

Note: This is a somewhat theoretical article on programming. It is a basic knowledge to put the knowledge of Object Oriented Programming on a more solid foundation, but if what you are looking for is a direct explanation on what are objects, classes and things, you can read the article.

We begin by listing the concepts that we are going to deal with: Abstraction, Encapsulation, Modularization and Hierarchy.

Abstraction

It is a mental process by which the characteristics of something are ignored, keeping what really matters to us. The key to understanding it is “mental process”, so we have to think, extracting what really matters to us and ignoring what is superfluous.

Abstraction is something that humans constantly do in our day to day. If we didn’t do it, our brain would collapse with all the information that surrounds us. For example, to go to the university or to work you go by bus. What is the abstraction of the bus? It is what interests us as passengers, the price of the ticket, the line that travels, the departure times, etc. We don’t care if you move with gasoline, gas or electricity. Nor do we care about its displacement, power, consumption, the company that manufactured it or the year it was made, or the age of the driver, to give several examples. So we are abstracting from many details and staying with the fundamentals.

However, abstraction is a subjective process. The bus mechanic will carry out another type of abstraction, keeping certain details that interest him due to his profession. For example, he will care if it is diesel or gasoline, the manufacturer, year, type of engine, transmission, suspension, etc.

One way to manage software complexity is to get code written in such a way that it allows for abstraction. In assembler, the biggest application they could make was 10,000 lines of code. Then, with high-level languages, they reached 100,000, 300,000, 600,000, and that was achieved thanks to procedural abstraction. Therefore, in traditional programming, the incorporation of functions or procedures brought with it an abstraction that changed the world. Something as simple as having functions that perform procedures and which we can call by sending parameters, abstracting from their complexity. The algorithm of that function can be done in a thousand different ways, recursive, iterative, with a for loop, while, etc. But all these details matter absolutely nothing to the person who is going to call this function, what is essential for him is the name of the function, the parameters and the return type.

encapsulation

It is the process by which the details of the support where the characteristics of an abstraction are stored are hidden. At this point the key detail to understand is in the word “support”. When we encapsulate we are saving how something is supported, how it is stored, what medium it is, what its name is, etc. You will understand it better with an example.

It’s like when they give you an encapsulated medicine, where you don’t see what’s inside. You can only touch the capsule but you do not see if there is powder inside, a tablet, the color it has, etc. Nobody wants you to handle the medicine and that is why they give it to you encapsulated. They tell you “take this” but they don’t allow you to touch or see what’s inside. Probably because the capsule is designed to dissolve in the right place and not interact with saliva from the mouth, or perhaps with intestinal juices. They sell you a computer and give it to you encapsulated, so you don’t open it. You don’t touch what’s inside a computer, you only touch what they want you to touch, such as the keyboard, mouse, on and off button, etc.

In computing, encapsulation is also common. Think of a date. First we have an abstraction that would be “day / month / year” (of all that a date can tell us, we can only keep three fundamental data). Now, I can save a date in many ways, with three variables that hold those values, called day, month and year. Although the variables could be in English, day, month, year. We could also use an array of three elements where I have those three values, or with the number of seconds elapsed since a given date (known as a “timestamp” as traditional operating systems like Linux keep the date). Or maybe you want to save a simple string. If a programmer when writing a program deliberately hides from you how he has stored that date, then he is encapsulating.

Furthermore, it should be added that if a programmer reveals how he saved that date (for example, he used such and such a variable) and lets others touch those variables freely, he will be causing serious problems. You schedule a treatment for the date and potentially infinite numbers of people can use it. But if everyone accesses the fundamental features of the date abstraction (those variables) and manipulates them, the problem occurs: The day the date programmer regrets it and wants to start treating the date in another way, for example with the “timestamp” (number of seconds since 1970), because it observes that there is a noticeable improvement in the internal processes of the program when using this support, it would force all those who use dates to change their code. That is, if infinitely many people mention the variables with which that programmer saved the date (the essential characteristics of the abstraction), all the programmers who used the date will have to update their code to now access another variable and treat the date. in a different way, producing a fierce coupling that leads to waves of maintenance and loss of money in working hours.

The first moment where encapsulation appeared in the world of programming was with the local variables of functions. Local variables are specific to a function and cannot be mentioned from outside, so they are encapsulated. And note that languages ​​did not always allow encapsulation, engineers were slow to realize that it was beneficial not to touch the variables that were inside a function.

Finally, we must insist that the information is not hidden, the programmer who programmed the date has to inform you at all times about the day, month and year, if you ask him, what he does not let you know or touch are the variables or any other support by which you are storing the date.

Modularization

It is the decomposition of a system, creating a series of pieces that collaborate with each other, loosely coupled and cohesive. Modularity is taking a system and having the ability to segment it into various independent parts that make sense.

As a system we understand the broad concept that we must all have in mind. For example, a living being (a plant, man…), or part of a living being (the nervous system, circulatory system, etc.), or any type of product or organism (from a car, a bicycle, to a university or company, the solar system, etc). In any of these systems we must recognize various parts and we can observe that they all collaborate with each other to carry out an objective or set of tasks.

As coupling we understand the changes in parts and the degree of repercussion in other elements of the system. That is, I have a part of the system and I change it. This immediately affects other parts of the system, so that this degree of impact is called coupling. Loosely coupled means that changes in elements of the system have little effect on others.

For example, in a university, if something happens to the rector, it is not a reason for the university to stop working. Probably the teachers are not finding out that the rector has passed away and they continue to teach the class without any type of interruption. That’s because the rector is loosely coupled with other parts of a university.

The best systems are loosely coupled, because they allow me to make changes to parts without affecting changes to other parts of the system. But there may be more coupled and less coupled systems, because coupling will always exist. If we have a piece that does not have any connection with any other part of the system, it is probably because it is part of another system. For example, the big toenail has zero coupling to other parts of the respiratory system, and that’s because it’s not part of that system. In summary, if a piece does not collaborate with anyone, it is simply because it is not part of that system and therefore, the couplings must be reduced, not canceled.

Cohesion in a well modularized system implies that its modules must be understandable by themselves. The term comes from coherence and means that the parts of a system must function in a given way on all occasions and, furthermore, that operation must be well understood, without needing to explain an indeterminate amount of additional data that may not be part of the system. that piece.

In programming terms, a cohesive module looks like when you can explain it by looking at its own code. If when explaining it you have to talk about code that is scattered elsewhere, other structures stored in variables outside the module, then it is not cohesive. If you are given a code of a module (a function, a procedure, class…) and you understand it without resorting to other parts of the project, then it is cohesive.

Modularization goes hand in hand with abstraction and encapsulation, since these concepts represent the necessary tools to make cohesive and loosely coupled modules. Encapsulating reduces coupling, because changes to things inside a module do not affect the rest of the modules in the system.

Modularity goes hand in hand with abstraction. If I understand a piece by itself it is usually because it is a good abstraction. We focus on the essential characteristics of something, it is not a conglomeration of things without connection or without meaning. Therefore, the correct abstraction allows us to understand the pieces by themselves and therefore have cohesive modules.

Hierarchy

It’s the structure…