13

I've seen some legacy code that uses lengthproperty on some objects and others that uses length() method. Currently I'm working with a NodeList from the org.w3c.dom package and I found that it have the getLength() method to get the numbers of elements.

My Question is how as Java developer I can know how to determine when to use length, length(), size(), getLength()? obviously it depends of the object type and the API is there for read... but the point is how the Java Development select which of that implements in their classes.

Note: In the Question When to use .length vs .length() Makoto answer's indicates that .length is a property on arrays. That isn't a method call, and length() is a method call on String. But, why is the reason? why not use ever a method or ever a property for maintain the consistency around all the API.

Community
  • 1
  • 1
PlainOldProgrammer
  • 2,725
  • 5
  • 22
  • 30
  • Hey, the Java API has cruft dating back from nearly 20 years, ya know... Anyway, the convention nowadays is mainly to use getters, so you'll see `.getLength()` more often than not. Well, a `Collection` has `.size()`... – fge Dec 16 '14 at 18:04
  • 5
    Java doesn't have properties. length is a field. For arrays you use length, for Lists you use size(). There are going to be loads of classes out there with fields and methods with all sorts of names, so this is very hard to answer, but if you press . after an object your IDE should come up with a list of all the stuff you can do with it. – Paul Boddington Dec 16 '14 at 18:04
  • You'll have no chance but have to look up the documentation for each type you want to use. – 5gon12eder Dec 16 '14 at 18:05

5 Answers5

8

how would Java developers select which of [the methods] to implement in their classes?

When you implement classes that contain other objects, it's almost always going to be size(), the method provided by theCollection interface.

As far as other choices go, you should avoid exposing member variables, even final ones, because they cannot be accessed through an interface. Java gets away with it for arrays because of some JVM trickery, but you cannot do the same. Hence, length should be out: it remains in Java because it's not possible to change something that fundamental that has been in the language from day one, but it's definitely not something one should consider when designing new classes.

When you implement your own type that has length (say, a rectangle or a line segment) you should prefer getLength() to length() because of Java Beans naming conventions.

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
  • Very good answer and +1 for that. I have mentioned your answer in my answer. Just doubting why Jesper's answer was +3'd and yours wasn't!! – Am_I_Helpful Dec 16 '14 at 18:15
5

obviously it depends of the object type and the API is there for read...

You already have answered your question yourself: look in the API documentation of whatever class you are using.

but the point is how the Java Development select which of that implements in their classes.

The classes in Java's standard library have been developed over a long period of time by different people, which do not always make the same choice for the name of methods, so there are inconsistencies and unfortunately you'll just have to live with that.

Jesper
  • 202,709
  • 46
  • 318
  • 350
  • Pretty useless reason as per my view. See `dasblinkenlight`'s answer OR mine. I doubt why was this upvoted thrice! – Am_I_Helpful Dec 16 '14 at 18:14
  • @shekharsuman I think that I interpreted the question differently than you. I thought the question was: "Why did the people who designed the standard lib choose such inconsistent names?", while you probably think the question is "what name should I choose when I design a class?". – Jesper Dec 16 '14 at 18:20
  • Now,I am myself confused about this! Might be because my take is 2nd one which is what you mentioned! But,I guess OP's intent is the same as mine! – Am_I_Helpful Dec 16 '14 at 18:21
2

There is no clear rule, otherwise we wouldn't see such a mixup in the jdk itself. But here are some things to consider when making such a design decision.

  1. Don't worry to much. It is a minor thing and won't make to much of a difference. So when you think longer then 5 minutes about this, you are probably wasting money already.

  2. Use getters when a frameworks need them. Many frameworks depend on the getter style. If you need or want such frameworks to work nicely with your class it might be beneficial to use that style.

  3. Shorter is better. the 'get' part doesn't increase clarity. It just generates to characters of noise to the source code, so if you don't need it for some reason, don't use it.

  4. Methods are easier to evolve. Length is often a quantity that is not set directly but somehow computed. If you hide that behind a method it gives you the flexibility to change that implementation later on, without changing the API.

  5. Direct field accesses should be a tiny bit faster, but if you aren't working on high volume online trading or something, the difference isn't even worth thinking about. And if you do you should do your own measurements before making a decision. The hotspot compiler will almost for sure inline the method call anyways.

So if there aren't any external forces driving you in a different direction I would go with 'length()'

Jens Schauder
  • 77,657
  • 34
  • 181
  • 348
0

According to OOPS principles, length should be attribute and getLength() should be method. Also length attribute should be encapsulated should be exposed through methods, so getLength() sounds more appropriate.

Unfortunately not all Java library classes follow standards. There are some exceptions and this is one among them.

Pranalee
  • 3,389
  • 3
  • 22
  • 36
-3

In a pure OO language it should be probably always a method like length(). So in a class hierarchy you can override the attribute length.

But Java is not pure OO. And the main reason for fields (.length) vs method (length()) is/was performance issues.

And even Sun/Oracle programmers did some bad class design.

PeterMmm
  • 24,152
  • 13
  • 73
  • 111
  • 1
    the strong distinction java makes between methods and fields has nothing to do with OO. Also in OO there is nothing that specifies if you should prefer getX or just X. – Jens Schauder Dec 16 '14 at 18:08
  • it has to do how Java founder understand or has interpreted OO. They said Java is a OOL. The background is really to broad to discuss as a programming question. – PeterMmm Dec 16 '14 at 18:11