Developer tips

Getters and Setters Are Not Evil

Every now and then some OOP purist comes and tells us that getters and setters are evil, because they break encapsulation. And you should never, ever use getters and setters because this is a sign of a bad design and leads to maintainability nightmares.

Well, don’t worry, because those people are wrong. Not completely wrong of course, because getters and setters can break encapsulation, but in the usual scenario for regular business projects they don’t. What is the purpose of encapsulation? First, to hide how exactly an object performs its job. And to protect the internal data of an object, so that no external object can violate its state space. In other words, only the object knows which combination of field values is valid and which isn’t. Exposing fields to the outside world can leave the object in inconsistent state. For example what if you could change the backing array in an ArrayList, without setting the size field? The ArrayList instance will be inconsistent and will be violating its contract. So no getter and setter for the array list internal array.

But the majority of objects for which people generate getters and setters are simple data holders. They don’t have any rules to enforce on their state, the state space consists of all possible combinations of values, and furthermore – there is nothing they can do with that data. And before you call me “anemic”, it doesn’t matter if you are doing “real OOP” with domain-driven design, where you have business logic & state in the same object, or you are doing fat service layer + anemic objects. Why it doesn’t matter? Because even in domain-driven projects you have DTOs. And DTOs are simply data holders, which need getters and setters.

Another thing is that in many cases your object state is public anyway. Tools use reflection to make use of objects – view technologies use EL to access objects, ORMs use reflection to persist your entities, jackson uses reflection to serialize your objects to JSON, jasper reports uses reflection to get details from its model, etc. Virtually anything you do in the regular project out there requires data being passed outside of the application: to the user, to the database, to the printer, as a result of an API call. And you have to know what that data is. In EL you have ${foo.bar} – with, or without a getter, you consume that field. In an ORM you need to know what database types to use. In the documentation of your JSON API you should specify the structure (another topic here is whether rest-like services need documentation). The overall point here is that you win nothing by not having getters and setters on your data holder objects. Their internal state is public anyway, and it has to be. And any change in those fields means a change has to be made in other places. Change is something people fear – “you will have to change it everywhere in your project” .. well, yeah, you have, because it has changed. If you change the structure of an address from String to an Address class, it’s likely that you should revisit all places it is used and split it there as well. If you change a double to BigDecimal you’d better go and fix all your calculations.

Another point – the above examples emphasized on reading the data. However, you must set that data somehow. You have roughly 3 options – constructor, builder, setters. A constructor with 15 arguments is obviously not an option. A builder for every object is just too verbose. So we use setters, because it is more practical and more readable.

And that’s the main point here – setters and getters are practical when used on data holder objects. I have supported quite big projects that had a lot of setters and getters, and I had absolutely no problem with that. In fact, tracing “who sets that data” is the same as “where did this object (that encapsulates its data) came from”. And yes, in an ideal OO world you wouldn’t need data holders / DTOs, and there will be no flow of data in the system. But in the real world there is.

To conclude – be careful with setters and getters on non-data-only objects. Encapsulation is a real thing. When designing a library, a component or some base frameworks in your project – don’t simply generate getters and setters. But for the regular data object – don’t worry, there’s no evil in that.

11 thoughts on “Getters and Setters Are Not Evil”

But one must be very careful, because when you start with getters and setters everywhere it is very easy to create a system where you have only DTO’s + some classes with static methods that operate on those DTO’s – in this case you fall back into procedural paradigm.

If one says getters and setters are bad *always*, one is an idiot.
However, getters and setters are too verbose, while in 90% of the time they do nothing more but to set/get a value.

There are frameworks that provide annotations for automatic getters/setters where no additional code is required. Unfortunately they all have major drawbacks, because they are not inside the language but something on top of it.

I’m thinking that this paradigm can be taken a bit further with virtual getters/setters: if some field is public – use it directly. if there is a getter, call the getter even though the caller called the field directly.

On one of the sites that published my posting, I also said that – having something like the .NET properties would be beneficial. It’s syntactic sugar, yes, but it adds to the “practical” side of things.

While I agree to some of your statements, Getters and Setters (G&S) are still pointless by definition. I for one don’t care how an object does a thing, but I do care for *what* it does.

Since any added logic to that encapsulation would result in bad naming, G&S must, by definition, *only* either return or set a value. As I said, everything else would break naming. In the case of Getters and Setters correct naming results in useless functionality.

What considers containers G&S become the most higher-level functions available. Hence, their usage here may be justified, but again we’re drifting away from that concept by using a higher-level abstraction: Iterators.

* Does getDate() consider the current timezone or not? Who knows? Maybe someone like you hid some complex logic behind it? Time to investigate how the object does its task…

* What happens when performing a “c.set(Calendar.MONTH, 13)”? Well, Java’s “Calendar” doesn’t throw an error but raises the year and adds the remaining months. This may come unexpected.

* Assume I need to access data very, very fast or I want to be flexible in the way I do validation, your validating G&S would probably drive me nuts.

Also, performing 13 consecutive function calls in order to set some variables is error-prone and time-consuming (in both counts: human and machine).

“A constructor with 15 arguments is obviously not an option.” Why isn’t it an option? Or, rather, if your constructor have 15 arguments, isn’t there already a code smell that hints that this class is doing “too much”?

If the class won’t be in an operable state upon initialization, then what is the point of having a constructor at all? The constructor, by definition, is the method that “prepares” (initializes) the class for usage. If the constructor is not able to initialize the class to a state of proper usage, that means that the constructor is not doing its job properly and that the constructor should be fixed.