Perhaps the statement best practice was a little strong, or at least taken out of context.
I was aiming towards the idea that for value transfer objects - effectively structs from C/C++, public finals are a perfectly acceptable option and in my opinion preferable to getters for the same purpose. For these kind of immutable value objects, they introduce less chance that you will get anything but the immutable values for those fields, the principle of least surprise. On top of that, you save a bunch of boilerplate as well. Since the references are final, there seems little to be gained by making them private and restricting access through getters unless you want to somehow add behavior to the accessor methods - and if you do that you probably aren't wanting value objects in the first place. Of course, as mentioned, this idea definitely works out best with final references to immutable objects, but will behave the same as getters even if the objects referenced are not immutable - you still end up with the same references from the direct access or from the getter, what you do with it after that is your choice. Scala has uniform access for properties, so that eliminates the distinction (getXXX methods are only generated when you need compatibility with JavaBeans for some reason). For everything else though, I would still claim that final publics are a good idea when all you want is a "struct". Cheers Dick On Nov 20, 7:03 pm, bertvv <[email protected]> wrote: > Well, Dick was making the case of the functional programming style, > where immutable objects are the way to go. So a class should > definitely not evolve to a mutable version... > > On Nov 21, 1:40 am, Christian Catchpole <[email protected]> > wrote: > > > > > I don't know specifically what dick was talking about, but my concerns > > are: > > > - does this give you dual methodologies for field access? members vs > > getters > > > - a reference may be final (maybe immutable) now, but what do you do > > if your class evolves to where the reference is now mutable? > > > - even though a field is final can the caller still modify the > > object? I guess you can argue the same for any getter though. > > > On Nov 21, 10:02 am, Moandji Ezana <[email protected]> wrote: > > > > At his Devoxx talk, Dick casually mentioned that making final fields > > > public > > > was now a best practice. I do this sometimes on my non-work projects, but > > > feel a little dirty. I doubt it would fly at work. > > > > I thought it was too trivial a point to bring up as a question after the > > > talk, but what do you guys think? Is making final fields public > > > acceptable? > > > > Moandji -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=.
