I like the last few arguments about multi threaded environments. That makes the getter/setter paradigm desirable even in single user environments.
Thanks for the thoughtful arguments. On Fri, Jul 12, 2013 at 8:01 AM, sebb <seb...@gmail.com> wrote: > On 12 July 2013 15:39, Ajo Fod <ajo....@gmail.com> wrote: > > I wonder what conditions justify the use of protected / public fields? > > > > I can see how protected fields make more sense for a single user code > > because it is easier to not have all those getter/setter methods. But > > perhaps for an API with a wide audience, the commitment of providing a > > field is a big one. Is this the general view? > > IMO there is one use case for which a protected field is suitable, and > that is a constant which only has use in the class hierarchy. > > Getters are much more flexible, and should be quickly inlined by the > compiler at run-time. > > Setters should be used sparingly; prefer immutable classes where possible. > > Remember that the Java memory model permits threads to cache variables > unless prevented by synchronisation. > If thread A modifies field F, thread B may not see the updated value > of field F immediately or at all. > Unless F is volatile, or unless A & B both synch. on the *same* lock. > Using getters/setters is one way to guarantee safe publication - make > both methods synchronised on the same lock. > > Properly encapsulated classes are much easier to test, as the fields > cannot change unexpectedly. > Classes with exposed mutable fields are basically impossible to test > fully in a multi-threaded environment, and not always easy in a > single-threaded environment. > > > -Ajo > > > > > > On Thu, Jul 11, 2013 at 11:57 PM, Benedikt Ritter <brit...@apache.org > >wrote: > > > >> A somewhat more academic rationale why making fields protected may be an > >> issue, can be found here: http://dl.acm.org/citation.cfm?id=28702 > >> > >> Benedikt > >> > >> > >> 2013/7/12 Ajo Fod <ajo....@gmail.com> > >> > >> > I see. That makes sense now. > >> > > >> > Thanks. > >> > > >> > On Thursday, July 11, 2013, Phil Steitz wrote: > >> > > >> > > On 7/11/13 12:09 PM, Luc Maisonobe wrote: > >> > > > Hi Ajo, > >> > > > > >> > > > Le 11/07/2013 20:38, Ajo Fod a écrit : > >> > > >> More classes can be used/extended if fields generally default to > >> > > protected > >> > > >> instead of private as it seems it does in classes in CM now. > >> > > >> > >> > > >> Case in point is in : > >> https://issues.apache.org/jira/browse/MATH-1003 > >> > > > In fact, having protected members is often not considered a good > >> thing. > >> > > > If for example you look at checkstyle VisibilityModifier check, > you > >> > will > >> > > > see that its protectedAllowed property is set to false by default. > >> > > > > >> > > > For Apache Commons Math, we have decided to not use the default > value > >> > > > and our setting in checkstyle.xml explicitly put protectedAllowed > to > >> > > > true. However, this does not mean everything should be protected > by > >> > > > default. It is rather a case by case decision, and we have a > tendency > >> > to > >> > > > prefer restricting access than opening it.: as you have noticed > there > >> > > > are more private than protected fields. > >> > > > > >> > > > In many cases, including the one you mention for inverting > diagonal > >> > > > matrices, its seems safer to add a protected getter for the field > >> than > >> > > > putting the field itself protected. It allows read only access to > >> > > > derived class which seems sufficient in this case. In some other > >> cases, > >> > > > a setter may also be added, but direct reference to the field > itself > >> is > >> > > > a dangerous thing that should be looked at precisely. > >> > > > >> > > +1 - we have mostly moved away from protected fields in commons > >> > > because once defined they become part of the public API. This > >> > > effectively locks us in to the specific data representation chosen > >> > > when they are defined, as well as obviously to the fields > >> > > themselves. Changing types or visibility breaks backward > >> > > compatibility. Protected fields are also directly mutable, making > >> > > thread-safety more difficult / expensive to ensure. > >> > > > >> > > Phil > >> > > > > >> > > > best regards, > >> > > > Luc > >> > > > > >> > > >> Cheers, > >> > > >> Ajo > >> > > >> > >> > > > > >> > > > > --------------------------------------------------------------------- > >> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> > <javascript:;> > >> > > > For additional commands, e-mail: dev-h...@commons.apache.org > >> > <javascript:;> > >> > > > > >> > > > > >> > > > >> > > > >> > > > --------------------------------------------------------------------- > >> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> <javascript:;> > >> > > For additional commands, e-mail: dev-h...@commons.apache.org > >> > <javascript:;> > >> > > > >> > > > >> > > >> > >> > >> > >> -- > >> http://people.apache.org/~britter/ > >> http://www.systemoutprintln.de/ > >> http://twitter.com/BenediktRitter > >> http://github.com/britter > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
