Naming conventions for complex getters in Java

Question

Hi there!

I was reading this MSDN article about the usage of properties and methods in .NET. It points out why and when to use properties or methods.

Properties are meant to be used like fields, meaning that properties should not be computationally complex or produce side effects.

Otherwise one should use methods.

I was asking myself how you could express this difference in Java.

What is your opinion?

Answer 1

C# Property is basically Java getter and setter in one. If I need use both geters and setters for one instance, I always choose property. In java, I don't have this option.

Answer 2

I just don't agree with what that article says. Properties are syntactic sugar, otherwise you'd just use fields.

The point of getters/properties is encapsulation - the user does not know whether it's simply a field, something you compute every time or a random value.

This means that for me, every class in Java that is not a "Data Structure" has getters and setters for its fields (that need to be accessible).

Answer 3

1. Create a private field and name it in the most relevant way.
2. Use your IDE to generate setters and getters

Direct field access is not recommended (at least by Bloch, Effective Java)

Answer 4

It depends. If all the operations are completely internal then getSomething() is okay even for complex implementation - the whole point of getters/setters/properties is to encapsulate implementation details and hide them, even if in the future they change to be something complex.

An exception to this is if the operation is so complex it might significant amount of time or resources (e.g. download some data from the internet). In that case I might use a different method name - it kind of breaks encapsulation but it's useful and practical.

If the getter has any observable side effects, however, I would probably not use the simple getSomething() convention, to avoid confusion. Maybe I'll use updateAndReturn() or getAndComplexify() or getFromWeb() or stuff like that.

Answer 5

I was asking myself how you could express this difference in Java.

Just don't use the get prefix on the method, as it normally implies that the method will be cheap (as getters usually only access fields, delegate to other getters, or perform fairly simple calculations based on other getters). For example, if a class has this interface:

class Blob {
    long getLength() { ... }
    ByteBuffer getBytes() { ... }
    Sha1Checksum getChecksum() { ... }
}

... it would seem that getting the length, contents, and checksum from the Blob are equally costly. If we did like this, instead:

interface Blob {
    long getLength() { ... }
    ByteBuffer getBytes() { ... }
    Sha1Checksum calculateChecksum() { ... }
}

... it becomes clear(er) that we can expect calculateChecksum() to be more expensive than the other operations, as its name says it's going to do more than just get something.

To a certain degree, the complexity is an implementation issue that shouldn't be seen in the interface (maybe I decide to calculate the checksum eagerly when the Blob is constructed?), but there are occasions where it makes sense to make a distinction.