Attention! Response with potential to cause controversy
You are right, most people follow these "recommendations" because they have seen somewhere and they who are "teaching" other people also do not know why they do this. Some think they know.
In fact, the answers given in the rray link show that < in> getter and setter by itself can not be considered encapsulation. Just because you left a private field (and not attribute) does not mean that you are encapsulating something, especially when you put a < in> getter and setter straight to it without thinking about what it is doing.
I am increasingly convinced that getter / setter and other methods that serve as a buffer to access the real state is abstraction and not encapsulation. Okay, I still can not say it with such force and I know it will not be well accepted because the definition that is usual in our environment, and even is formalized says that this mechanism is the encapsulation. So I do not expect people to change their vision and I will not dwell on it. It seems to me that encapsulation is leaving everything that is necessary to the object in the object itself. If someone asks more about it, I can give you an answer.
What's the point of having a deprivation field and a couple of methods that normally terminates the field in the same way that it would be accessed directly? How can this be encapsulation?
I think it may be abstraction, because abstraction assumes that the concrete inner mechanism does not matter.
Encapsulation has to do with the fact that the behavior to change the state of the object is next to the object itself. Then there will be a method that will make the change or access to the value of the field. But nothing says it should be getter or setter .
But it can be too. If the only behavior to access / change the field is directly related to the state purely and simply, that's fine. The important thing for the encapsulation is that the behavior that allows the access / mutation of the field is in the same object.
There is a caveat that you should never have setters and maybe getters methods. These people say, and even give reason, that they should have methods that have them do certain actions that will manipulate the state in some way, but that is not so straightforward.
I disagree a little because there are many cases that the only thing you should do with the field is change its value, and in most cases to get some data just get the value of the field.
Of course, people abuse, even by not understanding how to apply this technique correctly. When a class is full of getters and especially setters it really should have something wrong.
To illustrate using the max motivator in the comments above: you should not have getSaldo() and setSaldo() , must have Depositar() and Sacar() , among other methods that can change the balance. Maybe getSaldo() makes sense, but a simple method name change can give another impression, something like ObtemSaldo() or PedeSaldo () '. You need to understand what an operation is for giving good names.
Note that the Sacar() method does much more than just tinkering with the balance, it is not a simple setter , apart from the truism that it does not change the balance directly, it will do a subtraction .
If you use a constructor properly you have a very low need to use setters . The validation here can be considered as an encapsulation as Piovezan said in its response, after all it is close to its object.
Often the right one to get information is to get a set and not just a single field, there would also enter the same idea that the method should not only return the state of a field. Of course, to do this will probably create a complication because you may have to create a class just to support the set of fields that will return in a given situation.
Still following Piovezan's response, even though he has used the term getXXX() in some method, I do not know if everyone can be considered as getters . If it returns a subset of a data collection, is this by itself no longer a method with a special meaning? Calling getter means that it has no function other than to give a value, has no specific semantics, it happens to be part of the object's mechanism and not its meaning.
Note that some languages provide better mechanism for working with these things, such as properties and tuples.
I know this is somewhat complicated to explain, abstractions are poorly understood by humans. I need to find a way to better explain mechanism and semantics.
I'm still going to finish
