• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

public fields - can I loose points on that?

 
Gytis Jakutonis
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As you all know, public fields(non static ones) break encapsulation and are not acceptable by OOP fundamentals. However in some cases it is more natural to have public fields instead of bunch of accessors. In our case - database field format class, which stores information as field name, size, index, type(maybe), etc. Is it possible to loose marks for using public fields in this case?
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Gytis,
Are you sure you want public access to your fields? This means that any class can access them and possibly change them. In the cases where Sun allow access to fields within classes, they usually restrict the access by making the fields protected.
In general I would advise against making any field publicly accessible unless it is a constant. There is very little work needed to make accessor methods for your fields, and likewise very little work needed to use those accessors.
Regards, Andrew
 
Hanna Habashy
Ranch Hand
Posts: 532
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As you said it, it breaks encapsulation. It is just but OOP. I believe you may loos points. There are 40 points on OOP.
 
Mogens Nidding
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I must give the same advice: Don't make the fields public. If you really feel you must make them public, then at least make them final. Now that's said, I just neeeeed to make a personal point or two.
I'm not suggesting that you use getters and setters because I think it's the greatest idea in the world, but because it's the safest idea in the world, and because a lot of people (almost certainly including the examiner) will cut your head clean off if you even think otherwise.
My two main messages are: One, many people blindly criticize unencapsulated variable access. Those people should get rid of the "blindly" part. Two, if java had some syntactic sugar for getters and setters, it wouldn't be so much of a problem.
It is sad that you must flank every variable with a getter and possibly setter. It is even sadder that you must then write javadoc for the getters and setters. Even sadder still: In keeping with the javadoc style guideline, you should try to avoid documenting getX() with "gets the X", but try to write something genuinely informative that gives the reader an idea about what X is. Then watch your getter and setter documentation slowly get out of sync over time.
But the saddest thing ever is that in many cases, the getters and setters are all for nothing - for example because your code really doesn't need the encapsulation (because it was designed to cope with direct variable access, or because there really are no external clients), or because even if it turns out later that you do need the encapsulation, you usually have access to all the client code (if any!), so you can refactor at will, or because even if it turns out that there is client code that you need to change but can't, you are probably still home free by simply changing the interface nonetheless (perhaps deprecating the public variables for a time first) and letting the clients worry about whether and when they upgrade.
But look on the bright side: With plenty of autogenerated getters and setters, it will look as if you're spurting out twice as much code as you would otherwise!
C structs and Pascal records or classes with public variables usually work fine, and make for much shorter programs. GridBagConstraints might be a comparable java example although I didn't think a lot about it.
If only java or at least the standard javadoc doclet had some syntactic sugar for getters and setters, we could achieve the good effects of getter/setter encapsulation without the ill effects of excessive verbosity and redundant documentation.
In closing: Don't get me wrong, everyone. In principle, you should always encapsulate your variables, but with the current java(doc) syntax, I think it is sometimes more work than it is worth. That should count for something, too!
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic