I could not understand very well the encapsulation in the POO

Question

I took a course in programming logic and now I’m doing logic OO, but it’s come to the encapsulation part and I’m having a little bit of trouble understanding. What it would be and how it’s used?

Answer 1

My experience is that most courses talk about object orientation because everyone wants to learn it. And everyone wants to learn because they say it cures cancer. Which is far from the truth. It’s a shame because people keep looking for the sacred chalice of OOP and even learn other ways, do not learn when to use OO or not, and worse, usually do not learn the dear paradigm right.

OOP was not created to facilitate learning, on the contrary it is much more difficult to learn and make object-oriented code, and only those who are naive and do not learn right think it is easy, which obviously does everything wrong and does not benefit from what the paradigm promises, but she is not able to evaluate, she just trusts she’s taking some advantage.

Most of the so-called OOP codes we see around are not OOP or abuse resources that are not needed.

Don’t go to OOP without understanding the imperative very, but very well indeed. If you still don’t understand every detail of the code don’t go for more advanced concepts and not so necessary. Almost everyone ignores this tip, it’s a shame because those who have not ignored today are good developers and respond here while those who ignore keep bumping heads at every code they try to do.

Roughly speaking, because it has several definitions, and people can’t agree on what it actually is.

Encapsulation is to gather all the details about the object, besides it is usually exposed only what is established as a API, a guarantee, a contract that will never be changed, which already enters the abstraction. Everything that is encapsulated can be changed without problems, as long as it continues to fulfill everything that the class proposes. So both state and private behavior is created to meet class requirements without committing to a specific way of doing.

So much of what is said about encapsulation is confused with abstraction, even though they are different things. Even one of the mechanisms used for this is information Hiding which is not quite such a general technique, is something more specific and so is not a pillar of object orientation.

The encapsulation facilitates maintenance because it creates a closed box where the consumer does not need to know the details and has there everything he needs, as it is an object. You don’t need to know what’s inside, you don’t need to resort to other things to deal with that, what you need is there in the object somehow. Not exposing these parts avoids misuse or improper use, increasing the readability of the code.

It’s like a car, you need to know how to drive it, not how it works, even each car can work very different and you know how to use all of them, the differences are encapsulated and abstracted. You know the car, you don’t need to know about wheels, motor, electric, there’s a cohesion of what a car is.

Has several questions on the subject, I advise to read all and research more:

• Meaning of terminology: "Object oriented"
• What are the pillars of object-oriented programming?
• Why hide the implementation of a class?
• What happens in real life in a developer environment if the programmer does not encapsulate an attribute?
• Is it correct to say that encapsulation aims at cohesion? Why?
• What is the relationship between encapsulation and polymorphism?
• Programming for interface and not for implementation, why?
• In Object Orientation, an inheritance violates encapsulation?
• Getters and setters are an illusion of encapsulation?