Well, that, or @Data :P On Nov 23, 4:17 pm, Dick Wall <[email protected]> wrote: > 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=.
