|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 ?
what _are_ you talking about?
field visibility????
???? .... ?????
all this big noise over package visibility?
don't you guys have anything better to do ?
It's Friday night, MaD aNDy GO get a chick!
All this stress and pressure from the .bom?
Geez us!
marcf
2x(Programming Object Oriented)=?
|
|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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
