Public field variables OK?

[Jane Jukowsky]

I've been programming full-time Java for 12 years now, and of course common wisdom is that you don't have non-final public variables (at least for a non-trivial class anyway). I am beginning to think though.. if you are not selling your code, and if the class in question does not interface directly with your customers(internal or external), and given the ease of refactoring under an IDE, why the heck are we bothering creating boilerplate accessor methods just in case someone some day may need a non-trivial accessor? That's just too verbose. And with Hibernate, there are lots of business objects with lots of accessors. Yes, there are tools for generating those, but it's still weird to have so much empty code. Thoughts?

[Rob Spoor]

With public fields you have no control over what values it's given. If the requirements change an an int can no longer be negative, you would need a lot of changes if the field were coderanch. If you have a setter method instead you need to change only that setter method to include the check.

[David Newton]

Lots of tools *expect* JavaBeans. It's also easier to use AOP on methods (if you're not using AspectJ, like if you're using Spring AOP).

I agree that Java's lack of property support is irritating, but it's also not a big deal. I sometimes just create a base class with the properties and accessors to keep them out of my mainline code.

[Jane Jukowsky]

AOP and tools, sure. It's also true that, once your "accessors" stop being completely anemic, you have to have methods. But these scenarios don't cover all cases, and with the ease of refactoring these days, it's really easy to change a field variable into an accessor or two once than to maintain (add/remove/refactor) hundreds of accessors over the years.

[Dave Lorde]

It's not a simple consideration. I see it as a mix of 'Best Practice' and 'Slippery Slope'. There's no doubt that public access to class internals is a major risk to robustness and reliability, it increases coupling and compromises encapsulation and refactoring regardless of IDE facilities, and it makes testing, instrumentation, and dependency injection far more difficult. In a large application, especially with team development, keeping a high standard of code quality is essential, and once you start lazy practices, they can easily become 'lost' and forgotten in the code. Coding is still a mix of the technical with art/craft, and it seems to me that no self-respecting craftsman would be happy to release poor quality code. There are situations such as DTOs where pure data structures without operations are passed around, but as has been mentioned, these are increasingly expected to behave as Java Beans by framework tools, so the argument for public data even in these special situations is weakening.

[David Newton]

Jane Jukowsky wrote:
AOP and tools, sure. It's also true that, once your "accessors" stop being completely anemic, you have to have methods. But these scenarios don't cover all cases, and with the ease of refactoring these days, it's really easy to change a field variable into an accessor or two once than to maintain (add/remove/refactor) hundreds of accessors over the years.

If it's just an accessor, why would you have to "maintain" anything? I've never had to maintain an accessor, I almost never look at them or think about them.

They're irritating, and the lack of real properties *is* something I dislike about Java, but they're also inconsequential, and important for the reasons I already mentioned. While sympathetic, your argument is unmoving.

[Jane Jukowsky]

You are right in principle, but just a couple of points.

1. Technically, framework tools can access public variables just as easily as accessors. The only reasons they don't is because they are frowned upon by the community, so there is a confusion between cause and effect here.

2. I am not advocating a design that increases coupling. "x.y" is not any more coupled that "x.getY(). If, by contract, I replace the anemic getter by a public variable, that does not violate encapsulation either, simply because there is no difference between the two. What it does is lowers backward compatibility: when and if the getter needs to do anything different, stuff will need to be refactored and recompiled, which is annoying, granted. That's why languages like Groovy deal with it efficiently and don't make any difference between a getter and a public field variable.

3. I've been a purist and a big advocate of quality of code until my latest job. Here, I am a CIO at a tiny startup in charge of whipping together tons of low-quality code, fast, to keep us afloat, short term, and get us through a round of financing. Depressing, yes. Does it give me a license to bill my company an hourly rate to produce pretty code? Heck, no. A large part of the code is largely a throw-away anyway.

I've seen this business model during my work at Amazon. I was cussing there all the time seeing what ugly code people write - but Amazon has an explosive growth model, too, just like our startup. They simply can't afford to spend an hour refactoring. I know, I would not have believed this statement myself before I saw it. Seeing is believing. Their entire codebase changes simply too fast.

[Jane Jukowsky]

David Newton wrote:If it's just an accessor, why would you have to "maintain" anything? I've never had to maintain an accessor, I almost never look at them or think about them.

Trust me. I maintain my accessors a lot. Most of them are in my model and correspond rougly to hibernate tables. A small change in design, a change in a column name, and my accessors need to be reworked. (Yes, I know that my model does not have to closely correspond to my relational layer, but there has to be a good reason for disparity, and laziness is not such a reason).

Besides, hundreds of Hibernate annotations are mixed with these accessors.

Besides, some of them are anemic while others not - and it's not clear from looking at the class which are which. Very easy to fall for an assumption that all of them are.

Besides, a bit of non-accessor business logic is lost in the sea of that boilerplate stuff.

There has to be a better way to program. I am thinking I am tried of Java altogether.

[David Newton]

Jane Jukowsky wrote:Most of them are in my model and correspond rougly to hibernate tables. A small change in design, a change in a column name, and my accessors need to be reworked.

Yuck; I haven't hand-generated Hibernate models for years; at most I have to tweak a reveng file or two.

Besides, hundreds of Hibernate annotations are mixed with these accessors.

One of the reasons I am opposed to Hibernate annotations.

Besides, a bit of non-accessor business logic is lost in the sea of that boilerplate stuff.

Design, not Java, issue.

There has to be a better way to program. I am thinking I am tried of Java altogether.

Of course there is--Java is far from elegant; I'm only just now starting to achieve the same productivity in Java I had in Lisp or Smalltalk two decades ago, and that only because of stellar IDE support. This shouldn't surprise you--Java is like crack for people that like to type.

[Jane Jukowsky]

David Newton wrote:

Jane Jukowsky wrote: Besides, a bit of non-accessor business logic is lost in the sea of that boilerplate stuff.

Design, not Java, issue.

That's the whole idea behind POJOs, no?

There has to be a better way to program. I am thinking I am tried of Java altogether.

Of course there is--Java is far from elegant; I'm only just now starting to achieve the same productivity in Java I had in Lisp or Smalltalk two decades ago, and that only because of stellar IDE support. This shouldn't surprise you--Java is like crack for people that like to type.

so what's your language of choice these days?

[Jane Jukowsky]

Yuck; I haven't hand-generated Hibernate models for years; at most I have to tweak a reveng file or two.

Good point. I am stuck with hand-coding for historical reasons. Maybe i need to bite the bullet.

[Besides, a bit of non-accessor business logic is lost in the sea of that boilerplate stuff.

Design, not Java, issue.

That's the whole idea behind POJOs, no?

There has to be a better way to program. I am thinking I am tried of Java altogether.

Of course there is--Java is far from elegant; I'm only just now starting to achieve the same productivity in Java I had in Lisp or Smalltalk two decades ago, and that only because of stellar IDE support. This shouldn't surprise you--Java is like crack for people that like to type.

so what's your language of choice these days?

[David Newton]

Jane Jukowsky wrote:That's the whole idea behind POJOs, no?

Depends on what you mean by "business logic", I guess. There's business logic, then there's Business Logic. I'm always more likely to decorate a POJO somehow than embed big-Business Logic, but how/when this is done, and why, varies.

so what's your language of choice these days?

Depends--I haven't decided what *my* Next Big Language is, so I move between several that stay out of my way, each with their own benefits and drawbacks.

[Jane Jukowsky]

David Newton wrote:Depends on what you mean by "business logic", I guess. There's business logic, then there's Business Logic. I'm always more likely to decorate a POJO somehow than embed big-Business Logic, but how/when this is done, and why, varies.

Then you are not wholly buying into the concept of POJO, it sounds like? And how do you decorate? Say, there is a class Employee, and a class Shift, etc. - surely you don't maintain separate graph parallel to you POJO graph, just to avoid putting business logic into your POJOs? Otherwise, the whole idea of pojo flies in the face?

Depends--I haven't decided what *my* Next Big Language is, so I move between several that stay out of my way, each with their own benefits and drawbacks.

Perhaps a subject to a new thread? I'd love to know what languages people (you in particular) are programming these days, and what pros and cons there are. I am not happy with any language at this point.

[David Newton]

I have nothing against POJOs, but don't confuse a POJO with a class that is nothing but data structure--a POJO just means it has "no" dependencies. There's a bunch of ways to decorate; sometimes just subclassing works fine too.

I use Java, Groovy, Ruby, and JavaScript regularly; all four on the JVM, and Ruby/JavaScript off it. I'd like to re-start with Clojure as it's a Lisp, but lost track of it before 1.0 due to time issues. Smalltalk and Lisp (and their variants) were my hacking languages of choice until maybe five years ago... not sure if I'll return to them in a serious way or not, although Clojure and F-Script might land me back where I belong. For embedded systems I use C, Forth, and assembly, but might do my next projects in Scheme, or perhaps play a bit with some of Piumurta's (sp?) C-based ideas. Oh, I guess I use some embedded Java, too, although not much.

Languages I'd like to decide about, but won't, due to time: Scala is appealing on some levels but I have no time for the effort I feel it would require right now. For pure language geekery I'd like to pick up Ioke, but time will likely be a limiting factor for the next year or so. Things like Go and D have some draw, but again, time. Noop actually has some of the features I'd like to see in a new language, but it's obviously not very far along so we'll see.

(Boring Dave-language history redacted: name-dropping includes Io, OCaml, Erlang, C#, SQL, PostScript, Forth, Logo, Python, BASIC, and DSLs.)

Btw, if accessors are your big issue, why not try Lombok?

[Jane Jukowsky]

An interesting list, thanks for sharing. I miss Postscript!

What's the story with C#, why did you drop that? I hear left and right that it's superior to Java (ducking for cover :-P )

[David Newton]

What's the story with C#, why did you drop that? I hear left and right that it's superior to Java (ducking for cover :-P )

I think 3.0+ *is* better than Java, but I have no desire to work on Windows.

[Henry Wong]

David Newton wrote:

What's the story with C#, why did you drop that? I hear left and right that it's superior to Java (ducking for cover :-P )

I think 3.0+ *is* better than Java, but I have no desire to work on Windows.

Also, the concept of a language being "superior" over another implies that there is a language that can do everything better than another. Quite frankly, if all you care about is "throw away" code, and to get something up and running to get to the next round of funding, neither Java or C# is superior. You need a scripting language, that can generate code quickly, and have tools that can help with this.

This is why many startups like to work in Python or Ruby.

Henry

[Jane Jukowsky]

have nothing against POJOs, but don't confuse a POJO with a class that is nothing but data structure--a POJO just means it has "no" dependencies. There's a bunch of ways to decorate; sometimes just subclassing works fine too.

You'll have to agree though, subclassing a bunch of anemic objects to add business logic is icky. A necessary evil, perhaps. Although, one can think of them as interfaces.. stick them in a package where no one will see them.. it's OK I suppose, to a degree.

I am using Instantiations for my GUI editor, it's amazingly roundtrip. Why can't hibernate tools do the same? (or can they? I am not so familiar with them)

[David Newton]

It can, with assistance from the reveng file, and I almost always used custom templates to further control the data layer.