Question:
I researched about encapsulation, I even read some topics here, but I still haven't seen a real example of the use of it in a way that can show me its advantages, which problems it avoids.
I have an attribute of type public , but it is customary for programmers to make it private and create its get and set properties. Well, but they never show a real example, of a system that they have already made, of the advantages of using it and of the problems that occurred and were solved.
I saw examples in YouTube videos, but I don't see why they changed from public to private , they don't show what problems they would avoid. I've read some articles, watched some videos, but I just wanted a real and objective example showing the variables for the private because it avoids this kind of problem and the advantages are exactly those.
Answer:
It is not mandatory for an object to have a getter and setter for each field attribute (although exposing them directly as public is often worse). You have to create these methods only when it is necessary to directly expose the information (which generally shouldn't be the intention) and it doesn't even have to be the pair, it can be, for example, just one of them.
The object's internal fields are implementation details, along with the internal algorithms that handle them. In the spirit of object orientation is a more general principle which is to leave the implementation hidden and expose only a stable programming interface (a set of externally accessible – ie non-private in Java's case) methods that allows you to manipulate and make use of this internal state, and which does not necessarily have a one-to-one relationship with the object's fields.
A getter or setter can be half way there, if there is a need to actually expose this kind of interface. The article Encapsulation is not information hiding , which you may be interested in, cites the example of an object representing a geographic coordinate: latitude and longitude only admit certain ranges of values, and encapsulation helps to set them within valid limits. This is an example of setters that validate received values.
I don't use setters that much, but I do a lot of validation in constructors. If an argument parameter was passed incorrectly I already throw, for example, an IllegalArgumentException : "you are trying to construct the object wrong!" It is also a form of encapsulation.
In real projects I've also used a getter that needed to return a copy of a collection (you know what it is, right? A class that stores elements, like a list, a set, etc). Inside the object was a collection of immutable elements. I wanted to return a subset of this collection or else a copy of it, so that if the client code tried to modify the returned collection, it wouldn't modify my original collection. Modifying the elements was already guaranteed not to be possible, as they were immutable. So I made a getter that returned a copy or subset of the collection. Ready.
Another example: a getter that returned the connected status (true or false) of a control panel. This switch encapsulated a Java Socket and the connected information came from socket.isClosed() . Note that it's not a simple getCampo() or isCampo() . It does a processing, albeit minimal, which is inverting the returned value ( isClosed() returns if it's closed, I had an isConectada() that returns if the connection is open).