Hello Michiel!
This is a good example.
Having the field protected allows for subclasses to change it. Your
comment about making it final suggests that you are not expecting
subclasses to change it.
If subclasses aren't supposed to change it, I prefer to have a getter
method for that purpose. Examine what happens when doing changes to the
code.
1. Change the type (data structure) of the field.
2. Change the initialization of the field (using a setter instead of the
constructor argument).
protected final field:
1. All subclasses need to be changed immediately.
2. We loose the enforcing of the "subclasses should not change it".
protected getter:
1. Author of the class changes the getter to work as before,
deprecation, pointing out a new getter for an improved data structure...
2. No change in the relation to the subclasses.
/Linus
> -----Original Message-----
> From: Michiel van der Wulp [mailto:[EMAIL PROTECTED]
> Sent: den 25 maj 2006 09:23
> To: [email protected]
> Subject: [argouml-dev] Protected instance variables (was: Coding
> conventions)
>
> Hi Linus,
>
> See e.g.:
> public abstract class StateBodyNotation extends ValueHandler
> it has:
> protected Object myState;
> Encapsulating this would needlessly complicate matters - the class is
> abstract anyhow.
> This variable is _meant_ to be used by the class's offspring.
>
> PS: I guess this variable should have been made final. Isn't it?
>
> Regards,
> Michiel
>
>
>
>
> ----- Original Message -----
> From: "Linus Tolke" <[EMAIL PROTECTED]>
> To: <[email protected]>
> Sent: Thursday, May 25, 2006 12:16 AM
> Subject: RE: [argouml-dev] Coding conventions
>
>
> Hello Michiel!
>
> It is unlucky that you are feeling that Eclipse warns too much. I
don't
> understand from your description, where your warnings come from.
>
> Having instance variables "protected" means that the encapsulation of
> the generalized class is not as good if they were "private". How many
> extra lines of code are you contemplating per specialized class to
> enforce the only "private"-rule?
>
> /Linus
>
> > -----Original Message-----
> > From: Michiel van der Wulp [mailto:[EMAIL PROTECTED]
> > Sent: den 24 maj 2006 22:12
> > To: [email protected]
> > Subject: Re: [argouml-dev] Coding conventions
> >
> > Hi Tom,
> >
> > I feel the same, if you know how to set Eclipse such that it gives
me
> > only usefull warnings, I am all ears.
> >
> > Currently, it always gives a few warnings for every function with
> > parameters, and I do not find any way to suppress these warnings.
> > So I try not to look at them, and switched off checkstyle warnings,
> > since they drown in the useless ones...
> >
> >
> >
> > > 1. revise the coding conventions to something that we'll ALL use
> (and
> > are
> > > easily supported by our tools) 2. come up with a set of
> > > Eclipse/Emacs/whatever settings that support our conventions 3.
> enforce
> > > conformance by asking the author to make revisions to
non-conforming
> > commits
> > > rather than changing their code for them 4. when reformatting old
> code,
> > > make the minimal change which will bring the code into conformance
> 5.
> > Stop
> > > mechanically resolving checkstyle warnings without adding value -
> this
> > just
> > > masks real problems
> > > (e.g. adding comments like /* Constructor */ or Javadoc @param
> tags
> > with
> > > no contents)
> >
> > I thought we agreed on all this, only the tooling does not work, and
> > some of the less-obeyed conventions are about peanuts, and I even
> > disagree about some.
> >
> >
> > E.g. the cookbook says:
> >
> > <All instance variables are private.
> > This is not required by the Sun Code Conventions but an additional
> > requirement for ArgoUML.
> > This is checked by Checkstyle. >
> >
> > I like to use protected instance variables. Can I remove this
> requirement?
> >
> >
> > Regards,
> > Michiel
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.7.1/347 - Release Date:
24/05/2006
>
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.7.1/347 - Release Date:
24/05/2006
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
