CODEWITHSUNDEEP
javanaming-conventionsgetter-setter
Simon
Simon

Reputation: 9365

Naming conventions for complex getters in Java

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?

Upvotes: 2

Views: 1119

Answers (4)

gustafc
gustafc

Reputation: 28905

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.

Upvotes: 5

Oak
Oak

Reputation: 26898

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.

Upvotes: 3

abyx
abyx

Reputation: 73028

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).

Upvotes: 3

Xorty
Xorty

Reputation: 18861

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.

Upvotes: 2

Related Questions