What is Object-Oriented Programming

We start with our Object-Oriented Programming Course, with this first introduction in which we will see what it is, where it comes from, and what its purpose is.

Object-Oriented Programming (OOP) is a programming paradigm based on the concept of “objects”, which are entities that encapsulate data and behaviors, and the relationships between them.

Object-Oriented Programming seeks to achieve:

• Modularity: Allows the division of a system into independent components that can be developed, tested, and maintained separately.
• Reuse: Facilitates code reuse through class inheritance and composition.
• Flexibility: Allows the software to be adapted to changes in requirements or the execution environment more easily.
• Scalability: Enables scaling the software by adding new objects and classes as needed, without affecting the existing structure.

Without too much fear, we can say that it is the programming paradigm that has had the most influence in the last 50 years.

But before we start talking about classes, inheritance, and interfaces like crazy, let’s begin by looking at where it comes from, and why it is so important.

Where does object-oriented programming come from?

Let’s go back 50 years. At that time, computers were in their infancy 🐣, and neither the tools nor the program needs were what they are today.

In a way, “everything was to be done”. But what was clear at that time is that it was convenient to group data in containers, or structures. For example, if you had a person, it was logical to have

Person {
	string Name;
	string Surname;
	DateTime Birthdate;
}

This grouping was convenient so that we could work with a Person together. Otherwise, you ran the risk of mixing the Name of one person with the Birthdate of another.

Furthermore, these groups could be composed. In other words, one of your groups could contain other groups within it. For example, imagine you wanted to create a program that draws geometric shapes.

Point2D {
 int x;
 int y;
}

Shape {
	Point2D Position; // composition with Point2D
	int Rotation;
	int Width;
	int Height;
}

Where Shape uses Point2D as a position. So far so good. We have our data containers, very pretty and very practical.

Now you could use your shape, and use it to create Squares, Rectangles, Equilateral Triangles, and Circles. You simply used your Shape container, and filled in the data as needed.

The problem arises when, in addition to data, behavior needs to be added. Imagine that we want to add a function that calculates the area. It makes sense for a shape to know how to calculate its area, because it is an internal aspect of the shape, not dependent on anyone else.

At those times, the natural tendency to solve this was to use function references as members of your group. For example,

Shape {
	Point2D Position;
	int Rotation;
	int Width;
	int Height;
	
	int GetArea(); // we have added a reference to a function
}

But of course, a Rectangle, a Circle, and an Equilateral Triangle do not calculate their Area with the same function. Well, no problem, since it is a reference, I change the function as needed.

And you’ve messed up… 3000 lines, and 217 files later, when you called a function you had no idea what function you were calling because it had been changed 14 times throughout the program.

Imagine the problem of having to make a payment, and not being 100% clear on what the function is doing! Well, probably you will end up being fired or sued.

Object-oriented programming

By doing it this way, the situation got really messed up. There was no way to create good programs like this, it was not sustainable. So, very intelligent people started thinking.

They thought a lot. They visualized 12-dimensional universes. They modeled the world. They laid the foundations for a new programming paradigm.

In other words, they were not only trying to solve a problem. They were trying to invent a methodology that allowed the systematic resolution of any programming problem. Which is not a small thing.

After much thought, they said, we’ve got it 💡! What we need are four pillars:

• Abstraction, through objects
• Encapsulation
• Inheritance
• Polymorphism

We will see these four pillars in due course, what they are, and what function they covered. But the important thing today is to emphasize that they are not “magic laws” or absolute truths. It is what they needed to fix the mess they had created.

Object-oriented programming today

A lot of time has passed since the foundations of object-oriented programming were established. During this time, many things have changed.

Currently, there are even more detractors of object-oriented programming. Wondering if it is a paradigm that is still relevant today, or has become outdated. Well, several things happen here.

On the one hand, current needs are not the same as when those very intelligent people sat down to think. Programming is now much more complex, and covers needs that were not even envisaged at that time.

On the other hand, object-oriented programming has also changed. In fact, it has become more complex and more rigid. Even, in the words of some of its creators, it has evolved and deviated from the original purpose.

That does not mean that object-oriented programming is bad or outdated. On the contrary, we have said that it is a paradigm that arises naturally, as you make programs increasingly complex.

What is necessary is to understand the foundations and the purpose of each of them. It is not a problem of the paradigm, but of its use. It is necessary to know how to apply it, and adapt it to modern times.

That’s what we’ll focus on in this course, where we will see all these things. Where each of them comes from. And the practices that make sense to apply today, and those that are best to avoid.