0

On a project that I am working on, we are debating when to use get (getFoo) vs a normal name (foo) in java. When I look around in java core and guava, I see that there are many examples where get is omitted. Is there any doc that covers when guava or new java APIs will use the get prefix and when not to? Is there a convention these developers use here?

Thanks for taking the time to read this.

Examples:

ByteBuffer : http://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html#compact() ForwardingObject : http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/collect/ForwardingObject.html#delegate() Stopwatch : http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/base/Stopwatch.html#elapsed(java.util.concurrent.TimeUnit) Ticker : http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/base/Ticker.html#systemTicker()

EDIT:

As of http://download.oracle.com/otn-pub/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/beans.101.pdf, "A Java Bean is a reusable software component that can be manipulated visually in a builder tool." In our code base, the issue of get vs no get comes when the code has nothing to do with value or data objects (objects that represent data). When the class represents data, we are fine doing get.

My main question is why both java and guava choose to use non get methods for non data objects and what are their conventions.

ekaqu
  • 2,038
  • 3
  • 24
  • 38
  • Funnily enough, the [Google java style document](https://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s2.3.1-whitespace-characters) seems to cover everything but getters and setters. – maaartinus Sep 23 '14 at 18:36
  • stick to the javabeans naming convention. Every open source java project expects you to obey this convention. – DwB Sep 23 '14 at 19:59
  • Why compact should be getCompact? – Marco Acierno Sep 23 '14 at 20:51
  • 1
    The alternative convention, used for 'fluent' builders, is to have have the setter be Type foo(argtype), and the getter be argtype foo(). – bmargulies Sep 23 '14 at 21:43
  • @bmargulies. Good point - can you give my answer an upvote please? :-) – user949300 Sep 23 '14 at 22:29
  • I think that this questions is too broad/opinionated and should not get answered; it should get a few comments and get closed. – bmargulies Sep 23 '14 at 23:59
  • @bmargulies I think that this question is not too broad. It doesn't query the world, it basically ask "what are the reasons for". Opinions may come, but there are answers stating compatibility with existing frameworks, which may be a decisive factor for the OP (or someone else). – maaartinus Sep 24 '14 at 04:33
  • Note that for compatibility with Java beans, you must give up fluent style as well. Writing `x.setA(a).setB(b)` would be a nice compromise, but the setters must be void for the beanism to accept them. Also watch out for properties named like `uShaped` as they get interpreted inconsistently (half the tools expect `getuShaped` (really, small "u") or switching from `boolean` to `Boolean` ("is" to "get" for whatever reason). Unfortunately, sometimes the prefix gets used for non-properties involving slow computation (`File.getFreeSpace`), sometimes it's mixed (`setExecutable` vs. `canExecute`). – maaartinus Sep 24 '14 at 04:47

2 Answers2

1

The get prefix comes from the JavaBeans Conventions, which states that if you have an accessor for a property, then the accessor method's name must start with get, unless it is a boolean (the primative type), in which case is should start with is. Note that you use the get prefix to return type Boolean.

Throughout most of Java's API this is the convention that is used, which would be my recommendation as well. Your decision is up to you, but whichever convention you pick, I would suggest to be consistent and not mix the two.

DwB
  • 37,124
  • 11
  • 56
  • 82
blacktide
  • 10,654
  • 8
  • 33
  • 53
  • My main question is why and when do both java and guava choose to not use get. get/set for data objects is fine, the main question that we have is why is this convention not followed for non data objects. – ekaqu Sep 23 '14 at 20:40
  • 2
    @ekaqu The convention isn't followed for non-data objects because it it only designed to apply to data objects. See also [this link](http://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html#a28) for why the collections classes don't follow the bean convention. – Tavian Barnes Sep 23 '14 at 21:48
0

While the idea of dropping the "get" appeals to me, the problem comes when you also have a setter. You would have to do something like

public String name();   // getter
   and
public void name(String newName);  // setter, xor use the below **instead** but not both
public Foo name(String newName);   // if you prefer fluent/builder style

Which "looks weird" to a Java programmer. And until 1 minute ago I thought it was illegal, and my original post mistakenly said so until I tested it. You learn something everyday...

Added in response to @DwB

One good reason to use get/set is that many 3rd party frameworks expect this convention, as they use reflection to reason about your class. However, a framework could be able to look for combinations like the above, or be configured to use these methods instead of the usual get/set. This was almost in my original post but I haven't used Spring, Hibernate etc. in a few years so I'm not up to speed on what some of them will on won't allow if you aren't using get/set.

For example, Jackson can use annotations and mixins to define mappings, no need to follow get/set convention. I would think that Spring, JSF etc. could do likewise, (somebody please edit this answer with details as needed) though with some extra work. Whether this extra work is worth the "conciseness" of eliminating get/set is unclear. I'd say no, but YMMV.

user949300
  • 15,364
  • 7
  • 35
  • 66
  • pretty sure what you've written above **is** illegal - you can't overload a method with 2 implementations which take the same args (`void name(String)` & `Foo name(String)`); but if you meant that you thought method overloading in general was illegal then rest assured that it's not :-) – Armand Sep 23 '14 at 19:47
  • You can't do BOTH void and Foo, you have to pick one of them. Will edit post to say "xor". – user949300 Sep 23 '14 at 19:49
  • this is a terrible idea for Java. The JavaBeans naming convention is foundational to Java. deviating from this convention will cause no end of unexpected issues since everything expects you to follow it. – DwB Sep 23 '14 at 20:00
  • 2
    @DwB not the end of the world, is it? – Armand Sep 23 '14 at 20:09
  • only the end of using any existing java framework like springMVC, JSF, JSTL tags, gson, jackson, cxf, and many others. – DwB Sep 23 '14 at 20:23
  • My main question is why and when do both java and guava choose to not use get. get/set for data objects is fine, the main question that we have is why is this convention not followed for non data objects. – ekaqu Sep 23 '14 at 20:41
  • All the examples above use java beans as data objects, so will convert data to another format. This holds true for java and guava, but when the class is not a data object this convention is some times violated, which leads to the question, when and why? – ekaqu Sep 23 '14 at 20:43
  • @DwB see edits. At least some frameworks can use annotations or other techniques to work around the get/set convention. – user949300 Sep 23 '14 at 22:27
  • @DwB No idea about the others, but Gson doesn't care about properties, it uses [fields exclusively](http://stackoverflow.com/a/6205039/581205). – maaartinus Sep 24 '14 at 04:26
  • good to know about gson – DwB Sep 24 '14 at 12:26