<rant> I agree with Kevin. Java used to have a 'private-protected' access modifier that was synonymous with C++ protected but they dropped it after 1.0. This was a bad idea, IMHO. Often you'd like to restrict access to variables to the class and its subclasses only. Protected doesn't give you this as it gives package access as well.
The other thing lacking in Java is specifying how a class subclasses another class. Allowing private inheritance or protected inheritance is often very useful, especially when using a few of the common design patterns. The default public inheritance that Java uses does not provide the kind of control that is often necessary. FWIW, I find that the encapsulation in Ant is poor also. I had a hell of a time subclassing an Ant task because the authors had half of the instance vars private and half protected for no apparent reason. I couldn't override some of the methods I needed to because I needed direct access to the variables in the superclass or an accessor method--neither of which was possible/available. I don't think that enough engineers put enough though into WHY they use particular access modifiers when designing code. Many of my colleagues tend to make the interface public and all internal data and methods private which makes extensibility very poor. </rant> Charles -----Original Message----- From: Kevin Steppe [mailto:[EMAIL PROTECTED]] Sent: Friday, January 04, 2002 12:21 PM To: [EMAIL PROTECTED] Subject: Re: Log4J encapsulation is poor In my opinion Java lacks the best access modifier for OO code -- access for the class and its descendants but no one else. Protected is close, with package being a possible choice too. Public access doesn't restrict me and rarely causes problems even though it's theoretically bad, however not being able to properly extend a class because something is private is a real problem that requires a lot more work to get around even if it's theoretically better. You wouldn't believe the number of times I've wanted to strangle javasoft for making a class un-extendable through careless use of private. My question then becomes -- are protected or public variables causing you a problem? Why? Are the engineers at Tivre modifying them directly, and if so can't you just tell them to stop it? Package access matters only if you're working within the Log4J scope in which case you're developing Log4J as opposed to just using it, so that shouldn't be an issue. Kevin Christopher Randall wrote: > I just have a question/comment about the Log4J code. It seems like there > is a vast amount of exposure to instance variables in the code that I > don't quite understand. I see a lot of public, package-access, and > protected instance variables. Why does Log4J expose these data members? > > Was this done for a specific purpose, or were the original authors just > lazy coders? If there is a purpose, can someone please explain it to me? > > Thanks, > Chris > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
