[logback-dev] field encapsulation in logback classes

[Harris, Carl]

There are apparently many examples of fields in logback classes that are not private to the class implementation.  For example, SyslogAppenderBase contains seven examples of mutable fields that are not private.  Best practice would suggest that unless there's a really good reason to break encapsulation by exposing such fields, they should be private.  In the case of SyslogAppenderBase there appears to be no reason for exposing most of these fields; apparently the "private" modifier was omitted as an oversight.  Properly marking fields as private is a significant aid to project contributors, in that the scope of the field is explicit and limited.  Moreover, it is much easier to contemplate making changes to a properly encapsulated class.

I propose that as a general practice, logback contributors should mark all mutable fields as private and expose properly documented accessor methods with appropriate access modifiers as a better alternative to allowing field state to directly accessed and possibly modified.

Comments or opposing opinions?

carl






-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.qos.ch/pipermail/logback-dev/attachments/20130425/1d44d6e8/attachment.asc>