Getters on an immutable type

Question

I am writing some immutable types in Java and wonder about how to name the accessor methods. The Java Bean specification says that the names of accessors should be getX or isX, but since the fields are final, there is no setter and the fields are more like attributes than properties.

There for I'd prefer naming the getter methods like:

public T x()

rather than

public T getX()

Please note as an example:

public int java.lang.String#length()

(Which might have been specified so early in the Java history, so the conventions where not there yet.)

The immutable objects expose means to create modified versions of themselves through methods which I've tried to name like a verb rather than MyObject MyObject#setX(), this should limit the risk of the user calling setX() and think that the object has changed. So: MyObject MyObject#shine(newShineLevel).

This is not always possible easy though. How would you name a method for adjusting an endpoint in a rectangle other than Rectangle.setUpperLeft()? Rectangle.adjustUpperLeft maybe, but now we're just moving away from the conventions.

I guess the question is relevant for all languages, but this questions concern Java in particular.

Answer 1

Even for immutable types, the convention getX() still stands. Some examples:

• java.lang.Integer.getInteger()
• java.lang.Boolean.getBoolean()

It is true that there are also many examples such as java.lang.String.length(), but the common convention is to use getX. Just as mentioned in the answer below, it is crucial to separate between an atomic get operation, and a method which does some calculations on the data.

Also worth mentioning that plain java beans in many frameworks depend on the fact that getters/setters are conveniently named getX and setX.

Answer 2

The convention in Java for accessing properties of a class -- including immutable classes -- is to use the get and set prefixes so I would recommend using public final T getX().

The reason the length() method on a String isn't called getLength() is because there is no property called length on the String class.

Answer 3

If these classes may be used with any reflection based framework then you are better off staying with the getX convention. For example, accessing properties in JSPs and other templating systems via an expression "x.y" requires that the object have a method getY().

Answer 4

People tend to down-vote me when I say this, but the get prefix is really only mandatory if you're writing a bean. There are lots of examples of where get is not used. not only String.length(). You find it in the primitive wrapper classes (intValue(), doubleValue(), booleanValue(), ...), enums (name() and ordinal()) and collections (size()), and the way annotations were design also seems to encourage the get-less style. (Josh Bloch covers the subject in Effective Java, and advocates the more readable get-less style unless you're actually writing a bean.)

So: Use the get prefix and your object can be used as a bean. Ditch it, and your code gets easier to read. It's up to you to decide what you think is more important.

Myself, I usually use the prefix even though I dislike it, simply because Eclipse auto-generates it for me :)

Answer 5

I'd stick with the "get" convention simply because so many other tools work with it. Jakara Commons BeanUtils for example. Lots of tools/libraries will work by default if you have the right naming, but require configuration if you've deviated from the bean accessors convention.

I'm not disagreeing with you reasoning for deviating, I just think you're probably better off in the long run sticking with the get/set convention.

Answer 6

It's a good idea to use get--never mandatory, but people will automatically know what it's for.

Get does not imply that you have that as a member variable, in fact it's supposed to hide that fact. It can easily be giving access to a computed value.

size(), length(), etc were created before Borland found they needed the get/set concept to implement their GUI builder (I'm not sure exactly who came up with the idea, but that was the reason).

intValue, doubleValue etc are not getters, they are converters and therefore are named differently.

Now, all that said, if you really want to use x or getX it is your choice. getters and setters are no longer needed for most decent toolsets, they will use annotations instead--just be ready for a few people to take a few extra seconds typing "get" followed by "ctrl-space" and not finding what they are after.