Beside private Attributes I think you should always make
the members private and add Setter/Getter methods. Even
the developer of the class does not see how it could be
useful only the people inheriting this class can tell
if it is useful or not.
This make Attributes "object-oriented" and also solves
the problem of overwriting of Attributes which can produce
very strange errors because member overwriting is bound to
the static type (type declaration) and not to the dynamic
type. Therefore the same reference can lead to different
attributes.
IMHO we should slowly but surely migrate the old, prototype
looking code to a more robust coding.
My Guidelines for this would be:
1) all members are private
2) all not-private members have setter/getter methods to
access and manipulate it with the appropriate access
keywords
3) setter/getter methods contains JavaDoc explaining the
purpose of the attribute (setURL() doesn't tell you
much)
4) Whenever someone violates this rules he/she has to add
JavaDoc to explain the rational behind
What do you think ?
Mad Andy
BTW I know that I violated this rules but this would not mean
that we bring all code up to date in the near future but give
all developer the right but also the duty to update the code
they are currently working on.
> -----Original Message-----
> From: Jason Dillon [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 03, 2001 3:42 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] package level fields
>
>
> > I think that the rationale behind making all your fields
> private is that
> > nobody can break design and access those fields. If you
> have a specific
>
> I agree.
>
> > design reason why a field needs to be accessed directly
> then you can open
> > up your field to allow access. Better yet is to control
> access through an
> > accessor or mutator.
>
> Again, I agree.
>
> > The idea that I am going to make my field <insert
> > acess modifier> just so that I can make it easier to extend
> goes against
> > all good object-oriented principles that I have ever
> studied. I tend to
> > agree with the original poster (and the Ant team for that matter).
>
> That is not what I meant. I was just stating that it might
> not be a good
> idea to blanket all fields with private, unless there are
> accessor|mutator
> methods where appropriate, as it might limit the reusablity
> of the given
> component (causing users to duplicate/re-write/introduce bugs/maintain
> changes with the original and so on). A good design of a
> pluggable system
> will take these factors into account along with the principals of
> containment and either design with delegates to allow customization or
> provide the appropriate access modifiers where necessary.
>
> I have had many frustrating hours adding additional behavior
> to Ant due to
> in appropriate use of the private keyword.
>
> --jason
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
