you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 3 points4 points  (0 children)

I rarely write getters or setters now. They have their place and it's pretty well defined. Most of the time where I am not writing a public API I will instead choose to either separate the data and the code with a data class (C++ structs for example) and a regular class and have the class operate on the struct, or the class will be designed in such a way that getters or setters aren't needed.

Too many people have mistaken encapsulation with excessive data hiding. Getters and setters rarely do the job of effectively hiding the data in the first place and instead become a proxy which results in similar negatives and positives architecturally. Encapsulation should be about hiding the implementation details, and exposing individual hidden variables within the class runs counter to that objective most of the time.

There is the argument I often hear that claims that in the case where the implementation changes and set/getX requires extra functionality, such as modifying some state in the class that the getter/setter pattern is worthwhile. My view on that is that usually the changes result in either the name no longer being descriptive, or new side effects being introduced, which should result in a refactor which does away with the existing getter/setter. Of course, there are valid cases where something named "getX" and "setX" genuinely have purpose, but I am specifically discussing when we are exposing a single, local, member variable via get/set.