Win a copy of liveProject: Protecting User Data with Spring Security and OAuth2 this week in the Spring forum!
  • 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
  • Paul Clapham
  • Ron McLeod
  • paul wheaton
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Liutauras Vilda
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Piet Souris
Bartenders:
  • salvin francis
  • Mikalai Zaikin
  • Himai Minh

Enum value is always null

 
Ranch Hand
Posts: 99
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just a small program whereby I add person information to a list and then its printed out to the screen when the loop is exited but gender is always null, why is that ?








Any help appreciated.



 
Saloon Keeper
Posts: 12876
279
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You never assign the gender field of your Person object.

Lesson: Make your fields final. What point is there in giving the Person class setters?

Another thing, never make your fields public. Provide a getter for the gender field instead.
 
Kevin O'Sullivan
Ranch Hand
Posts: 99
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:You never assign the gender field of your Person object.

Lesson: Make your fields final. What point is there in giving the Person class setters?

Another thing, never make your fields public. Provide a getter for the gender field instead.



Thank you !

when you say make the fields final, do you mean like this

 
Sheriff
Posts: 16140
269
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:
Lesson: Make your fields final. What point is there in giving the Person class setters?

Another thing, never make your fields public. Provide a getter for the gender field instead.


This is a rule that is getting harder to justify over time and it's worth understanding the context and reasons behind it. The second part about providing a getter is a good hint.

Why provide a getter?

Well, there are at least two reasons. The first is the notion of maintaining encapsulation. The thought is that the class itself should have sole control over the implementation of its properties and when and how they are changed. Thus, a direct assignment made to a property by any code outside the class is a no-no because that would break encapsulation by allowing the logic of changing or mutating the value of a property to exist outside of the class itself.

To avoid breaking encapsulation, you need to provide an intermediary setter (mutator) method that is responsible for maintaining encapsulation by being the "official" way to change/mutate a property from the outside. And since you have a setter, then having a getter as well makes the whole scheme for property access symmetrical. Hence the rule "provide a getter."

If you think about it, a final field can never be changed once it has been assigned a value so if the only concern was that of outside code directly assigning a value to a property, it's a non-issue because the language already prevents it. Thus, with final properties, a setter method is pointless and if you don't need a setter, wouldn't a getter also be unnecessary? In fact, without a matching setter, I would argue that adding a getter would make the class asymmetrical instead.

(NOTE: This is assuming that your getter is something like this: public int getXXX() { return this.XXX; } -- anything more complicated than simply returning the property value would probably justify a getter method).

Which brings us to the second reason for the "provide a getter" rule. Having symmetry by providing a matching getter for each setter is not just a matter of aesthetics and semantics. Providing getters and setters has to do mainly with the Javabean convention which assumes classes provide property accessors that follow the getXXX() naming pattern and setXXX() for mutators. If your class doesn't provide a getXXX() to access the value of the XXX property, your code will not work with frameworks that expect objects to follow the Javabean convention. That's it.

The downside to all this is that it makes Java code very verbose. Other JVM languages like Groovy and Kotlin have addressed the issue of verbosity by auto-generating these methods and thus effectively freeing the developer from the "no public properties, declare public getters" rule while still maintaining compatibility with the Javabean convention.

Bottom line is that the "no direct access to a property, provide a getter/setter instead" is something that you should follow in Java because of the way the language is designed and the Javabean convention but not necessarily something that's an absolute when we're thinking about good object-oriented programming style and maintaining encapsulation in general.
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic