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
