Getters and Setters Rebuttal

Counter article to This Article: Why “manipulators+private data” should be preferred over “public data”

Getters and Setters are a necessary component of OOP. We can all agree that there
are some cases where they are extremely useful, and other cases where it would be
silly to add them. My argument in this article is to persuade that ALL data should
be private, with according functions to manipulate said data. These functions could
be anything from Get and Set to Add and Subtract, so instead of referring to these
functions and getter and setters, henceforth I will refer to them as manipulators.

Many of you may take quarrel with the idea that public data should be avoided. Indeed,
public data seems like a reasonably useful concept. There has to be SOME data that the
user would need to freely modify, right? Well, the answer is almost always no. To freely
modify something means the user can do whatever they want to that data, including “Bad,”
generally unwanted things like overflow, underflow. I challenge you to find a scenario
where some public variable would be better off without some degree of management.

Another big argument against manipulators is that they are a sign of poor architecture
design. While abuse of manipulators, like creating a literal getter and setter for EVERY
private variable, may be a sign of a novice programmer (especially if they ONLY set
and get without restriction), well placed, thought out, and purposeful manipulators
can actually pave the way for a clean and re-usable interface design. Manipulators
also allow a layer of abstraction between the data and the code that manipulates
it. The layer allows for the easy creation of side effects when manipulating data,
which means when we inevitably make a mistake in the way we utilize data, we only
have to change our procedure in one place, rather than spending hours hunting every
location that the data is used.

The biggest problem with manipulators is that programmers are generally lazy. Most of
the time manipulators are neglected and improperly implemented to speed up the
development process. Instead of throwing away the manipulator concept all together,
we as programmers should aspire to properly utilize and implement manipulators
to provide the cleanest, most re usuable, user friendly interface we can.

Now, for my critique of the article on Typical Programmer

“Every getter and setter in your code represents a failure to encapsulate and creates
unnecessary coupling. A profusion of getters and setters (also referred to as
accessors, accessor methods, and properties) is a sign of a poorly-designed set of
classes.”

Again, this touches on the novice mistake of implementing simple literal GetX and SetX
functions. Properly implemented manipulators are far more useful and OOP friendly than
exposing raw data.

“…the code we are working on was already full of accessors and public variables”

HOLD THE FRONT DOOR. Did I read that right? You have PUBLIC data AND accessors?
PROGRAMMER!
WAT R U DOIN?
STAHP!

If you have publicly modifiable data, not only is the accessor redundant, but it’s
also rendered useless. How would any user know to use the accessor instead of just
the data itself, and beyond that, what user would want to go through the hoops of
using a function, regardless of how properly or poorly it is implemented, when they
could just use the data itself? It’s like leaving the top off the gumball machine
and still expecting people to pay a quarter for a gumball.

“Instead I think the IDE should yellow-flag every public member variable and accessor;

 they are warnings of bad design.”

I would agree with this, not because accessor are bad, but because public variables are bad
AND the combo of public variables and accessors is redundant and useless. see last comment.

“At least Java has refactoring IDEs and compiler type enforcement that make changing the
type or meaning of a public member variable easy to find and fix.”

This is also easy to change in C++ IF you make all data private and use manipulators.
You would only have to change the meaning of the data in the manipulator functions
themselves instead of everywhere the data is used.

“The correct inference is that getters and setters should be avoided because they break
the encapsulation OOP offers.”

…Except that properly implemented manipulators are far more effective at creating
encapsulated and clean interfaces than exposing data publicly.

“Pretty soon a folklore grows around how to correctly implement accessors, and
programmers focus more on implementing accessors the right way when they should be
trying to eliminate the need for them in the first place. You can see the same thing
with other OOP workarounds; the lore surrounding singletons is an even richer mine of
how to do the wrong thing the right way.”

OOP is not a perfect system. There are tons of flaws, one of which is the lack of a way
to create objects that can only exist once ever. Maybe I can write another article on
why singletons are useful later, but for now, I’m going to keep focused on manipulators.

“I’ve written hundreds of thousands of lines of code in my career, much of it in
object-oriented languages, and I have rarely needed to expose a member variable or write
an accessor.”

Exposing variables is, of course, generally bad design. Writing accessors for exposed
variables is DEFINITELY bad design. At least we seem to agree on that? I think you and
I have different definitions of accessors though. From what I’ve read, you seem to think
an accessor is just a function that ONLY returns a variable. I would argue that
any method that returns a variable usually after some modification or other logic is an
accessor. That last part is extremely important, and is in fact the biggest strength
of an accessor. If an accessor has no extra logic, it’s can probably be written differently
to have a better effect.

One Comment

Add a Comment

Your email address will not be published. Required fields are marked *