tags:

views:

191

answers:

6

I know that in Java, it is common practice to use "get" as a prefix to an accessor method. I was wondering what the reason for this is. Is it purely to be able to predict what it is returning?

To clarify: In some java classes (eg String) a variable like length can be accessed by calling "length()" rather than "size()". Why are these methods written like this, but others like "getSomeVariable()"?

Thank you for your time.

Edit: Good to see I'm not alone about the confusion & such about the size and length variables

+6  A: 

'get' prefix (or 'is' for methods returning booleans) is a part of JavaBean specification which is used throughout the java but mostly in views in web UI.

length() and size() are historical artefacts from pre-javabean times; many a UI developer had lamented the fact that Collection has a size() method instead of getSize()

ChssPly76
So you should always use get as a prefix _unless_ using a variable such a size()? But why?
PiPeep
No, you should use `get` prefix or (optionally) `is` prefix for booleans IF you want your class to conform to JavaBean specification. `Collection.size()` existed before JavaBean concept was introduced and it remains there for backwards compatibility reasons - that's not the example to follow.
ChssPly76
So it's fine to not use get on an accessor?
PiPeep
If you're not going to use your class as javabean - yes, it's fine. Calling a method 'whatShouldINameMyAccessor' doesn't make it any less of a method.
ChssPly76
Ok! Thanks! Answer accepted.
PiPeep
You should use get.
ColinD
+6  A: 

Because properties are nouns and methods are verbs. It is part of the bean pattern that is well-established and therefore expected by anyone using your class.

It might make sense to say:

String txt="I have " + car.GetFuelLevel() + " liters of petrol.";

or ...

String txt="I have " + car.FuelLevel + " liters of petrol.";

but not ...

String txt="I have " + car.FuelLevel() + " liters of petrol.";

I mean, it doesn't make sense to say "Hey, car. Go FuelLevel for me." But to say "Hey, car. Go GetFuelLevel for me." That's more natural.

Now, why did they break rank with String.length() and others? That's always bothered me, too.

Rap
the casing in your examples could use a once-over.
akf
He's probably been programming C# recently...
Nate
+4  A: 

The get/set conventions stem from the java Bean specification. So people strongly tend to use that.

And the .size(), .length(), and even .length attribute of arrays are all examples of Java's failures to follow its own conventions. There are many more, it's "fun" to discover them!

Nick Veys
+2  A: 

They may be failures to the specification, however they improve readability. size and length allow you to read the following line of code:

for (int i=0; i<thing.size(); ++i){

As...

While i is less than the thing's size...

There's no real convention behind this, but it does make it easier to translate into a sentence directly.

Malaxeur
+4  A: 

The get prefix is particularly useful if you also have set, add, remove, etc., methods. Of course, it's generally better to have an interface full of gets or full of sets. If almost every method has get then it just becomes noise. So, I'd drop the get for immutables and the set for builders. For "fundamental" types, such as collections and strings, these little words are also noisy, IMO.

Tom Hawtin - tackline
+1  A: 

The historical reason was that the JavaBean specification stated that accessors to class properties should be done with getPropertyName/setPropertyName. The benefit was that you could then use Introspection APIs to dynamically list the properties of an object, even one that you hadn't previously compiled into your program. An example of where this would be useful is in building a plug-in architecture that needs to load objects and provide the user access to the properties of the object.

You have different names to retrieve size in different classes simply because they were written by different people and there probably wasn't at the time a design guideline for naming class methods in a consistent manner. Once millions of lines of code had been written using these inconsistent names, it was too late to change.

Pedro Estrada