Why use getters only as opposed to marking things final? [duplicate]

Question

I'm working in a java role after working a couple years in functional programming. Our company was bought by google and I took a java role after the acquisition.

Coming back to java as a polyglot developer, I'm generating getters for immutable objects and I'm seeing it's a total hogwash.

Are there any reasons why the 'getField' convention should be used so prolifically? To me it seems almost horrifying at this point that so many libraries expect public getter methods to work with their functionality when simply making a field public and final would have the same effect as making only a getter on a public mutable field.

Why isn't it more of a common practice to ditch the setters and just expose a final field?

Answer 1

For flexibility -- this has to do with what happens when you change the class later.

If foo.x is a publicly accessible member (even a final one), and you decide that you no longer need that member, code which accessed that method is now broken.

If you have only provided a getter, then you can always provide a compatibility version of that getter which computes the value as needed, and code which worked before still works.

For example, suppose we are writing a Point class, and we decide to go from vector (x,y) to polar (angle, magnitude) representation to internally store the point's position. Code which looks for a member named x is now broken -- but I can always provide a method named getX() which computes the X coordinate of the point and returns it.

Answer 2

The first problem that comes up in such a design is "what if something isn't final anymore?" You've decided that 'no, you really do need to change that field sometimes' and so when you remove the final, you're left with a public int field; sticking out there for anyone to fiddle with.

The next problem is, you've got to keep using it. Its part of the public API of the class. If you decide later that it doesn't have any meaning in some future version of the refactored class because instead of defining a rectangle as "length of short side, length of long side" with those two fields being public, you've now refactored it so the internal representation is two Points so that you can use it more easily in AWT. But, you've got two fields there that you have to maintain, even though the internal code doesn't use them anymore.

This becomes even more 'fun' when extending the class. Because now everyone that uses the extended class also has those two public final fields that they have to maintain now and is part of their API.

The problem behind these last two examples is that you've exposed some of the implementation of the class to other things. This isn't so bad if the modifiers on the fields are such that they are restricted to only code you have written. A default (package) protection on a fields so that other classes in the package can access it directly? Not so bad. No getters on a private inner class? No problem at all.

Some tools out there use reflection and depend on getters and setters. One that most easily springs to mind is Expression Language used in JSPs that expects a Java Bean compliant object. If you have ${foo.total} it invokes foo.getTotal(). As soon as the code touches JSP, it becomes a bit of a pain to not have getters and setters (related SO) - decorators everywhere.

Answer 3

I'd like to add something people haven't mentioned:

You can override getters and setters and you can specify them in your interfaces. You cannot do this with fields.

Answer 4

First: It is reasonable to use Functions instead of fields, because the syntax is different! If you have Code which ist int x = point.x and you decide to change the internal representation of Point to a lazy model which calculates x only when needed, you would have to refactor all legacy code, since a public field access and a method call are fundamentally different: So the code would have to be rewritten to int x = point.x()

So why should we call accessor-Methods to fields getX() instead of just X() ? because it is convention. The argument because everyone does it is perfectly acceptable here. Why do we write Classnames in Camel-Case? Why do we first declare Fields and then Methods in a class? Why do we call the iteration-variable in a simple for-loop i ?

Because it is idiomatic. Almost every Java-Programmer will expect it this way and can easily understand and maintain your code if you follow theses conventions. If you choose a different style and choose different names and code-style you should have a really good reason why this other style is better, because it will make your code less portable and harder to maintain!

Answer 5

It's not always recommended, read for example the Android guidelines:

Avoid internal getters/setters

Virtual method calls are expensive, much more so than instance field lookups. It's reasonable to follow common object-oriented programming practices and have getters and setters in the public interface, but within a class you should always access fields directly.

Answer 6

The answer is that getters and setters give the library writers the flexibility to change the internal workings of their library without requiring users of that library to recompile every time a change is made. This area is called Binary or Behavioural Compatibility, and is one of the basics of Software Engineering and came about because exposing the internals of a class can quickly become a maintainence nightmare.

THere's unlikely to be any peformance benefit either in directly accessing a field instead of through a getter, unless your HotSpot compiler is sub-standard.

There are certain cases, e.g. small classes, where is can be considered unnecessary.

Renaming a final field and introducing a getter instead is a BC break. It will require the users of you library to recompile which will just piss them off (I've worked in situations where we were not allowed break BC, or there'd be legal ramifications)

As for making everything immutable and making a copy when a change is needed... try sorting an array with that logic. Immutability comes into play with concurrency when threads share data, but there's a lot more to it than just making everything immutable.

Your question is really a moan about why Java isn't Scala, and well the answer to that is that it's because it's Java.

Answer 7

I think it's mostly because of legacy reasons.

• Some of Java's older apis are not immutable (the Date class is a mutable object, there is probably an alternative in java 8 now). Thus an argument for using getters is to potentially return immutable instances of these older objects. This is in contrast with functional programming where everything is considered immutable by default.
• Making things public and final does not necessarily make them immutable in java. As a simple example if a List was final, the object might not be mutable but the contents within the list are (functional programming would return a new immutable list in this case)
• Java also has a JavaBeans specification which recommends the use of getters and setters. It supposedly aids in portability (which is probably why frameworks use this for reflection purposes, although some do inspect the fields itself)

Answer 8

Sometimes something you get from an object is stored internally as a field, and sometimes it isn't. The example I use with my students is a Date class. It would be madness to represent a date internally as a separate day, month and Year; you just use the number of days passed since some reference day. This ensures consistency, and makes it easy to compare dates and do arithmetic.

Of course, from the perspective of the user of your class, it's a different matter. They want to know about the month and the year and so on. So you compute those on the fly and expose them with getters.

To me, this is the very heart of programming: make things easy for your users and (if needs be) difficult for yourself. This means working from the outside in. Set up the API that your user needs and then worry about how to implement it. And as usual, if you happen to be your own user, it doesn't change a thing. Every piece of code has a user and a developer.

So imagine you're a user, and you want to ask object foo for its bar. In your world, your have to stop to consider how foo is implemented. Is bar an stored explicitly as a field, or is it computed on the fly?

This isn't just about saving the user time, the fact that a user has to think about implementation details shows a seriously leaky abstraction. As others pointed out, this means that you can't just change bar from a field to a value that's computed on the fly. Saying you "have to recompile" doesn't do justice to the impact. You have to track down every piece of code that calls your class and figure out what the impact is. This could be in another company, in another country, and it could be a decade later.

Good coding means worrying about you interfaces, because nothing costs more than changing an interface. Getters are good interface design.

Answer 9

I think a serious part of the answer is that Java developers are used to the convention of using getters and setters. If you use a different style, other Java developers will have a somewhat more difficult time reading your code. Considering that the convention doesn't really cost anything in terms of performance or maintainability, I believe that the increased readability is worth it.

Answer 10

I'm a big proponent of immutable domain objects as well, and have seen cases where encapsulating the field with a getter has sure come in handy.

One point to note is that the immutability of an object can be pretty useless if it's only so in a shallow way.

To illustrate the point, consider a class that has a final field (private or not) of type Date. Now the point of immutability is that your object won't change; it could be passed off to other methods, cached, shared around across threads, etc., without fear of anything changing.

But, consider if someone gets a hold of that date field. I'm not saying that Jimmy is malicious or stupid, but he can do some pretty surprising things, and there's no guarantee that he's not going to call date.setTime on that puppy.

So, what do you do? You use encapsulation. You make the field private and exposing it through an accessor (getter), which instead of returning the stored data object, creates a copy with the same value. Oh, and you do the same thing in your constructor (you wouldn't want Jimmy to hold on to the reference he passed in and do more malicious/stupid/surprising things, would you?)

Okay, so now you expose, say, 7 fields directly, and one via an accessor. And Jimmy comes along and wants to use your API, and, well, what the hell is going on? Is this guy giving me the fields directly? Or wrapping them in methods? Some of each? Can't we just be consistent, he wonders?

And in this case, yeah, I have to agree with Jimmy.

Answer 11

Use of accessors is convenient in the following cases:

• When, during some hairy debugging, you need to keep track of who is accessing a given field. If there is an accessor method, it is trivial to add the relevant tracking code in that method; otherwise, this is a more complex and protracted game of searching throughout all the code which potentially accesses that field (or it could be done with some instrumentation magic, but that's hardly simple).

• You might want at some point to save on memory, and replace your "final" field with a piece of code which recomputes the value dynamically, instead of keeping it around. Depending on the relative costs of CPU and RAM, this may be a worthwhile exchange -- and since it is a performance-related issue, it cannot be decided until actual measures have been made, i.e. quite late in the development process. At that point, changing an already existing accessor method is much easier than tracking all callers throughout the code base.

One important point is that Java was meant for big projects involving a lot of people; in such contexts, one cannot assume that recompiling the whole code is practical or even possible. Interfaces are where developer teams meet, and they are very hard to change. Modifying a field access into a method call is an interface change.

On the side of pure performance, Sun pretends that the JIT compiler is smart enough to inline calls to simple method, so that a trivial getter method actually costs nothing at runtime. Or so they say.

---

Of course, a convention is just a convention. The reasons above should be considered as arguments for using accessors generally, but that's not a dogma. It is more a reminder that the software development cycle is long, often involves a lot more people than initially envisioned, and short-term gains must be balanced against long-term costs. It is OK to use public final fields if that is fine for you; but remember that in any project involving more than one developer, you are not alone, and interface decisions impact everybody.

Answer 12

I fully agree with the doubts and conclusions of the author of this question.

IMMO in java getters are mainly used because people like "rules of thumb" like "all fields must be private and have a getter" and really don't understand why its the real reason behind this.

Its really annoying when i see a java "bean" with N fields and getter&setters for all the fields, and the people do this because "its object oriented" when in fact this totally breaks encapsulation and creates coupling and more coupling with code like that:

  instance.getFoo().getBar().getFooBar()...

Sometimes you don't need and object, you need a data structure, its perfectly right put all field public and finals.

Sometimes you want an object, if you really want an object why you expose internal state with a getter?. off course you want to ask for something to your object (normally i prefer a tell don't ask approach, but not always is posible) ask you object for that value, but this its not a getter, this its a method that an object expose to give some information to the outside world, and by any means this implies that this object has a property holding this value!.

IMMO the term "getter" its for me one of the most notorious symptom of the big misunderstanding of object orientation in the community.