Are Java's public fields just a tragic historical design flaw at this point?

Posted by Avi Flax on Programmers See other posts from Programmers or by Avi Flax
Published on 2011-02-21T18:40:05Z Indexed on 2011/02/21 23:33 UTC
Read the original article Hit count: 213

Filed under:
|
|
|
|

It seems to be Java orthodoxy at this point that one should basically never use public fields for object state. (I don't necessarily agree, but that's not relevant to my question.) Given that, would it be right to say that from where we are today, it's clear that Java's public fields were a mistake/flaw of the language design? Or is there a rational argument that they're a useful and important part of the language, even today?

Thanks!

Update: I know about the more elegant approaches, such as in C#, Python, Groovy, etc. I'm not directly looking for those examples. I'm really just wondering if there's still someone deep in a bunker, muttering about how wonderful public fields really are, and how the masses are all just sheep, etc.

Update 2: Clearly static final public fields are the standard way to create public constants. I was referring more to using public fields for object state (even immutable state). I'm thinking that it does seem like a design flaw that one should use public fields for constants, but not for state… a language's rules should be enforced naturally, by syntax, not by guidelines.

© Programmers or respective owner

Related posts about java

Related posts about design