logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Hudak <CHu...@arrowheadgrp.com>
Subject RE: Log4J encapsulation is poor
Date Fri, 04 Jan 2002 20:29:11 GMT
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.


-----Original Message-----
From: Kevin Steppe [mailto:ksteppe@pacbell.net]
Sent: Friday, January 04, 2002 12:21 PM
To: log4j-user@jakarta.apache.org
Subject: Re: Log4J encapsulation is poor

In my opinion Java lacks the best access modifier for OO code -- access for
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
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.
wouldn't believe the number of times I've wanted to strangle javasoft for
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
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
to just using it, so that shouldn't be an issue.


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:
> For additional commands, e-mail:

To unsubscribe, e-mail:   <mailto:log4j-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-user-help@jakarta.apache.org>

To unsubscribe, e-mail:   <mailto:log4j-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-user-help@jakarta.apache.org>

View raw message