An object is not what you think it is
Building an object means starting with its behavior. The data it encapsulates is derived from that and constitutes an implementation detail.
Definition: Encapsulation
An object is usually defined as the encapsulation of data and the behavior that acts upon that data. This is, in fact, one of the four founding principles of Object-Oriented Programming (OOP). It is also a key difference from Functional Programming, in which functions act on data structures that have no behavior of their own and are passed to them as parameters.
The purpose of encapsulation is to protect the object’s state, that is, to ensure its consistency at all times. This is why this data must not be made public. The object’s state should only be modifiable through the methods it exposes, methods that reflect the actual interactions we can have with that object.
But then, what about setters and getters?
As a consequence of this premise, setters and getters, even if they adhere to encapsulation in theory, are an outright perversion of the principle of encapsulation: together, they expose the object’s inner workings and allow a third party to retrieve the data, update it (or perform some processing based on it), and put it all back into the object. In other words, a classic case of responsibility leakage, known as feature envy. In that case, we might as well keep it simple and assume that the data is public—which, once again, would be absurd.
This is precisely the meaning behind Allen Holub’s warning, “tell, don’t ask”: tell me what to do rather than asking me for the information to do it, since that is my responsibility.
It makes you wonder why so many IDEs still allow these methods to be generated automatically (*). Bad habits die hard.
Think of a black box.
Beyond that, this reveals a way of thinking that runs counter to the principles of OOP: many people, when creating a class, declare its attributes first and foremost. How could that be possible? Data serves behavior; therefore, without behavior, there is no data. When building objects, let’s truly think in terms of objects: objects that reflect the real world, objects with which we interact, not mere data structures.
A concrete example is worth a thousand words: see the code snippet.
Thus, to be precise, it would be more accurate to say that an object adheres to the principle of encapsulation. But an object is not the encapsulation of data and the behavior that acts upon that data. This is because we want to interact with an object as if it were a black box, without knowing anything about the data it uses internally to represent its state.
(*) Be careful with the word “get,” by the way: we French speakers use it for everything under the sun. What one “gets” from a person is no longer available to that person. This is rarely the behavior we want to implement.