Do we really need getters/setters?

#java #cleancode #discuss

In 99% of code, I haven't seen any logic in getters/setters, so it is literally the same as using public fields.

For me, nowadays, it looks like unnecessary stuff that we use out of habit.

So the question is, why do we continue using them? 
What do you think?

Top comments (12)

Mateusz Jarzyna • Jun 9 '20 • Edited

Since version 14, Java has the records

record Person (String firstName, String lastName) {}

var person = new Person("Joe", "Smith");
log(person.firstName())

There is nor getters and setters, records has something called accessor (similar to getter, records are immutable).

Anyway, many serialization frameworks (for example Jackson that serialize POJOs to JSON string) requires JavaBeans because of naming convention.

And of course encapsulation stuff, but @andrew (he/him) already mentioned that in his comment.

Andrii • Jun 9 '20

What I see in code in 99% of cases, private fields and lombok getters/setters, and I don't see any benefits of 'encapsulation' here, literally no encapsulation.

Andrew (he/him) • Jun 9 '20

Private fields with getters and setters that do nothing other than get and set are totally pointless, you're right. It's the ability to interrupt the user's command and do something else before getting or before or after setting that makes them useful.

Mateusz Jarzyna • Jun 9 '20

But serialization frameworks requires that convention. Hibernate/Jacson and other are looking for methods that starts with get/is/set to read or set the value.

Andrii • Jun 9 '20

As I know Hibernate does not always need getters.
But it is good point.

Andrew (he/him) • Jun 9 '20

Getters and setters are used when data needs to be encapsulated and/or validated. For instance, if you wanted to get someone's age, you should have something like

public int setAge (int newAge) throws IllegalArgumentException {
  if (newAge < 0 || newAge > 150) throw new IllegalArgumentException("invalid age!");
  this.age = newAge;
  return this.age;
}

rather than just having a public int age field. There are other situations where you might want encapsulation, without necessarily providing validation. For instance

private String myPassword;

public boolean checkPassword (String password) {
 ...
}

public void setPassword (String newPassword, String oldPassword) {
 ...
}

In this case, we want to provide a method for setting a new password, and checking against the current one. If you had a public field, this sensitive information could leak.

Katie Adams • Jun 9 '20

Seconding this. Encapsulation is very important for protecting sensitive data.

Andrii • Jun 9 '20

Yeah, I totally understand why it is theoretically needed.

But have you ever had such validation in setters?
or was it in some validation 'business' logic outside domain class?

regarding 'password' use case:

yes, of course, you should use setters where it is really needed, but in 99% you can have public fields without any problem.

Andrew (he/him) • Jun 9 '20

It's unusual, for sure, but so is directly getting and setting any state of a particular object, I'd say. The user usually doesn't interact directly with objects, but with some UI layer which then manipulates the objects, and -- as you say -- the validation is usually performed in that UI layer.

This might occur when trying to create objects without user input, like when reading serialized objects from a database. If your object schema has changed, you'll need to validate it before you can deserialize it. Slightly different from a setter, but the same general idea.

You're right that it's uncommon, but it's necessary.