Why use getters and setters/accessors? [Answered]

Query explained:

What’s the advantage of using getters and setters – that only get and set – instead of simply using public fields for those variables?

If getters and setters are ever doing more than just the simple get/set, I can figure this one out very quickly, but I’m not 100% clear on how:

public String foo;

is any worse than:

private String foo;
public void setFoo(String foo) { this.foo = foo; }
public String getFoo() { return foo; }

Whereas the former takes a lot less boilerplate code.

Why should I use getters and setters? Answer #1:

There are actually many good reasons to consider using accessors rather than directly exposing fields of a class – beyond just the argument of encapsulation and making future changes easier.

Here are the some of the reasons I am aware of:

  • Encapsulation of behavior associated with getting or setting the property – this allows additional functionality (like validation) to be added more easily later.
  • Hiding the internal representation of the property while exposing a property using an alternative representation.
  • Insulating your public interface from change – allowing the public interface to remain constant while the implementation changes without affecting existing consumers.
  • Controlling the lifetime and memory management (disposal) semantics of the property – particularly important in non-managed memory environments (like C++ or Objective-C).
  • Providing a debugging interception point for when a property changes at runtime – debugging when and where a property changed to a particular value can be quite difficult without this in some languages.
  • Improved interoperability with libraries that are designed to operate against property getter/setters – Mocking, Serialization, and WPF come to mind.
  • Allowing inheritors to change the semantics of how the property behaves and is exposed by overriding the getter/setter methods.
  • Allowing the getter/setter to be passed around as lambda expressions rather than values.
  • Getters and setters can allow different access levels – for example the get may be public, but the set could be protected.

Importance of getters and setters- Answer #2:

Because 2 weeks (months, years) from now when you realize that your setter needs to do more than just set the value, you’ll also realize that the property has been used directly in 238 other classes.

Answer #3:

A public field is not worse than a getter/setter pair that does nothing except returning the field and assigning to it. First, it’s clear that (in most languages) there is no functional difference. Any difference must be in other factors, like maintainability or readability.

An oft-mentioned advantage of getter/setter pairs, isn’t. There’s this claim that you can change the implementation and your clients don’t have to be recompiled. Supposedly, setters let you add functionality like validation later on and your clients don’t even need to know about it. However, adding validation to a setter is a change to its preconditions, a violation of the previous contract, which was, quite simply, “you can put anything in here, and you can get that same thing later from the getter”.

So, now that you broke the contract, changing every file in the codebase is something you should want to do, not avoid. If you avoid it you’re making the assumption that all the code assumed the contract for those methods was different.

If that should not have been the contract, then the interface was allowing clients to put the object in invalid states. That’s the exact opposite of encapsulation If that field could not really be set to anything from the start, why wasn’t the validation there from the start?

This same argument applies to other supposed advantages of these pass-through getter/setter pairs: if you later decide to change the value being set, you’re breaking the contract. If you override the default functionality in a derived class, in a way beyond a few harmless modifications (like logging or other non-observable behaviour), you’re breaking the contract of the base class. That is a violation of the Liskov Substitutability Principle, which is seen as one of the tenets of OO.

If a class has these dumb getters and setters for every field, then it is a class that has no invariants whatsoever, no contract. Is that really object-oriented design? If all the class has is those getters and setters, it’s just a dumb data holder, and dumb data holders should look like dumb data holders:

class Foo {
public:
    int DaysLeft;
    int ContestantNumber;
};

Adding pass-through getter/setter pairs to such a class adds no value. Other classes should provide meaningful operations, not just operations that fields already provide. That’s how you can define and maintain useful invariants.

Client: “What can I do with an object of this class?”
Designer: “You can read and write several variables.”
Client: “Oh… cool, I guess?”

There are reasons to use getters and setters, but if those reasons don’t exist, making getter/setter pairs in the name of false encapsulation gods is not a good thing. Valid reasons to make getters or setters include the things often mentioned as the potential changes you can make later, like validation or different internal representations. Or maybe the value should be readable by clients but not writable (for example, reading the size of a dictionary), so a simple getter is a nice choice. But those reasons should be there when you make the choice, and not just as a potential thing you may want later. This is an instance of YAGNI (You Ain’t Gonna Need It).

Answer #4:

Lots of people talk about the advantages of getters and setters but I want to play devil’s advocate. Right now I’m debugging a very large program where the programmers decided to make everything getters and setters. That might seem nice, but its a reverse-engineering nightmare.

Say you’re looking through hundreds of lines of code and you come across this:

person.name = "Joe";

It’s a beautifully simply piece of code until you realize its a setter. Now, you follow that setter and find that it also sets person.firstName, person.lastName, person.isHuman, person.hasReallyCommonFirstName, and calls person.update(), which sends a query out to the database, etc. Oh, that’s where your memory leak was occurring.

Understanding a local piece of code at first glance is an important property of good readability that getters and setters tend to break. That is why I try to avoid them when I can, and minimize what they do when I use them.

Answer #5:

There are many reasons. My favorite one is when you need to change the behavior or regulate what you can set on a variable. For instance, lets say you had a setSpeed(int speed) method. But you want that you can only set a maximum speed of 100. You would do something like:

public void setSpeed(int speed) {
  if ( speed > 100 ) {
    this.speed = 100;
  } else {
    this.speed = speed;
  }
}

Now what if EVERYWHERE in your code you were using the public field and then you realized you need the above requirement? Have fun hunting down every usage of the public field instead of just modifying your setter.

Answer #6:

One advantage of accessors and mutators is that you can perform validation.

For example, if foo was public, I could easily set it to null and then someone else could try to call a method on the object. But it’s not there anymore! With a setFoo method, I could ensure that foo was never set to null.

Accessors and mutators also allow for encapsulation – if you aren’t supposed to see the value once its set (perhaps it’s set in the constructor and then used by methods, but never supposed to be changed), it will never been seen by anyone. But if you can allow other classes to see or change it, you can provide the proper accessor and/or mutator.

Answer #7:

Thanks, that really clarified my thinking. Now here is (almost) 10 (almost) good reasons NOT to use getters and setters:

  1. When you realize you need to do more than just set and get the value, you can just make the field private, which will instantly tell you where you’ve directly accessed it.
  2. Any validation you perform in there can only be context free, which validation rarely is in practice.
  3. You can change the value being set – this is an absolute nightmare when the caller passes you a value that they [shock horror] want you to store AS IS.
  4. You can hide the internal representation – fantastic, so you’re making sure that all these operations are symmetrical right?
  5. You’ve insulated your public interface from changes under the sheets – if you were designing an interface and weren’t sure whether direct access to something was OK, then you should have kept designing.
  6. Some libraries expect this, but not many – reflection, serialization, mock objects all work just fine with public fields.
  7. Inheriting this class, you can override default functionality – in other words you can REALLY confuse callers by not only hiding the implementation but making it inconsistent.

The last three I’m just leaving (N/A or D/C).

Getters and setters- Answer #8:

Depends on your language. You’ve tagged this “object-oriented” rather than “Java”, so I’d like to point out that ChssPly76’s answer is language-dependent. In Python, for instance, there is no reason to use getters and setters. If you need to change the behavior, you can use a property, which wraps a getter and setter around basic attribute access. Something like this:

 class Simple(object):
   def _get_value(self):
       return self._value -1

   def _set_value(self, new_value):
       self._value = new_value + 1

   def _del_value(self):
       self.old_values.append(self._value)
       del self._value

   value = property(_get_value, _set_value, _del_value)

Hope you learned something from this post.

Follow Programming Articles for more!

About ᴾᴿᴼᵍʳᵃᵐᵐᵉʳ

Linux and Python enthusiast, in love with open source since 2014, Writer at programming-articles.com, India.

View all posts by ᴾᴿᴼᵍʳᵃᵐᵐᵉʳ →