The problem I have had is that I did originally want a struct of a certain structure, but then I changed my mind. For example I once made a Complex type this way with real and imaginary final fields, problem was I latter found that I was always multiplying and not adding the complex numbers. Then I wished I had magnitude and phase fields (which make multiplication easy). If I had used getters and setters I could have changed.
The thing that appeals about final fields is the short syntax both for writing the class and for accessing the fields, Scala style uniform access and case classes anyone. NB 1. Scala case classes aren't exactly what I would want since they expose the final fields, it would be better if the case classes only exposed the getters. 2. I can hear someone from the posse screaming properties in the background :) 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=en.
