And I understand the theory of why getters/setters are encouraged.
From my perspective that practice has been a code smell for at least the past 17 years - unless you're dealing with a DTO.
What is encouraged is to hide access to instance variables behind methods so that implementation details like validation, computation and storage can be hidden away and remain subject to change without impacting the object's public API.
Mindless getters and setters on the other hand hint at lack of design, revealing too much about the object's internal structure which causes its collaborators to be too tightly coupled to it.
Don't ask for the information you need to do the work; ask the object that has the information to do the work for you.
From my perspective that practice has been a code smell for at least the past 17 years - unless you're dealing with a DTO.
What is encouraged is to hide access to instance variables behind methods so that implementation details like validation, computation and storage can be hidden away and remain subject to change without impacting the object's public API.
Mindless getters and setters on the other hand hint at lack of design, revealing too much about the object's internal structure which causes its collaborators to be too tightly coupled to it.
That was exactly the point of this whole article.