• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Paul Clapham
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Roland Mueller
  • Piet Souris
Bartenders:

JavaBeans naming convenctions recap

 
Ranch Hand
Posts: 95
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi ranchers!
At Sybex book on OCA by Jeanne and Scott at page 206 there's a JavaBeans naming convenctions rules sum up.
They seemed easy and clear to me.
But when I got the relative review question ( n. 9 ) on these convenctions I miserably failed.
So I wanted to make a recap of these rules like I understood it. And make some questions

- Instance variables must be private. But static ones?
- Getters: if the property is a boolean must begins with is OR get. ie: public boolean isHappy(){return happy;} OR public boolean getHappy(){return happy;}. Can you give me a confirmation about boolean getters?
if the getter is another about java type it must begins with get only.
- Setter methods begins with set. ok

The rest of the name for getters and setters is the name of the property encapsulated beginning whith capital letters:
So for example we have a property called numberOfExams the getter and setters must be called
getNumberOfExams() and setNumberOfExams;
but names that shorten the original one one are valid as well?
getNumOfExams() and setNumOfExams; are also valid for JavaBean naming convenctions?

Hope you'll make me clear.  


 
Marshal
Posts: 28425
102
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
JavaBean naming conventions are in Wikipedia, here: https://en.wikipedia.org/wiki/JavaBeans#JavaBean_conventions.

By the way, static variables are irrelevant to JavaBeans. A JavaBean is an object which can be passed around to various users and it has various properties, which clearly can't be static.
 
Bartender
Posts: 2911
150
Google Web Toolkit Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:JavaBean naming conventions are in Wikipedia, here: ...


I think the correct link is https://en.wikipedia.org/wiki/JavaBeans#JavaBean_conventions
 
salvin francis
Bartender
Posts: 2911
150
Google Web Toolkit Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Btw, you have raised a good point about booleans. While typically, I would recommend to use "set" for setter and "is" for getter. There are situations where "is" does not sound grammatically correct e.g.


You could consider "has", "can", "contains" etc..
I hope my post does not raise a lot of eyebrows
 
Paul Clapham
Marshal
Posts: 28425
102
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

salvin francis wrote:You could consider "has", "can", "contains" etc..
I hope my post does not raise a lot of eyebrows



You could do that... but there are products like JSTL which just expect the name of the property (e.g. "vegetarian") and under the covers look for methods named "isVegetarian" or "getVegetarian" to access those properties. However your examples show that the JavaBeans conventions don't always work nicely with boolean properties.
 
Saloon Keeper
Posts: 5654
214
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Daniele Barell wrote:Hi ranchers!
(...)


hi Daniele!

Daniele Barell wrote:
The rest of the name for getters and setters is the name of the property encapsulated beginning whith capital letters:
So for example we have a property called numberOfExams the getter and setters must be called
getNumberOfExams() and setNumberOfExams;
(...)
Hope you'll make me clear.  


No, it is the other way round!
Suppose you have this class:

then you have the property: familyName, and its value is: lastName. You may be forgiven to think tht the property is lastName, to be retreived by the getFamilyName method, but as said, it is just the other way around.
 
Paul Clapham
Marshal
Posts: 28425
102
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And don't get hung up on the idea that the property is always represented by a private variable of the class. That's often the case, but not always. Consider this (trivial) example:



(In real life there are obviously more realistic examples.)
 
Enthuware Software Support
Posts: 4907
60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Piet Souris wrote:
hi Daniele!

Daniele Barell wrote:
The rest of the name for getters and setters is the name of the property encapsulated beginning whith capital letters:
So for example we have a property called numberOfExams the getter and setters must be called
getNumberOfExams() and setNumberOfExams;
(...)
Hope you'll make me clear.  


No, it is the other way round!
Suppose you have this class:

then you have the property: familyName, and its value is: lastName. You may be forgiven to think tht the property is lastName, to be retreived by the getFamilyName method, but as said, it is just the other way around.



True. In other words, a "property" of a class may not always have something to do with an instance variable of the class.  If you have a String getSalutation() method in a class, then that class has a saluation property of type String. Whether this method returns the value of an instance variable or fetches it directly from the database is irrelevant. If you also have a setSalutation(String ) in the class, then the property is editable otherwise it is just readable.

Similarly, if you have a isCertified or getCertified method that returns a boolean then the class has a boolean property named certified.
 
reply
    Bookmark Topic Watch Topic
  • New Topic