Jukka Zitting wrote:
I'm not so familiar with the jcr-server design that I can comment on
design decisions there, but in general i disagree with the above
principle. :-)
A method should be private if there is no specific reason otherwise. A
non-private method is a part of the external API contract of a class and
carries with it all the burden of API compatibility. The narrower the
API contract of a class is the easier the class is to restructure to
match an evolving environment. A narrower API is also easier to document
and maintain. In general it is much easier to relax the visibility of a
method when needed than to restrict the availability of a non-private
method.
ok, in general i agree with you, so let me refine the
principle: for jcr-server framework classes, especially but
not limited to those which are abstract concrete
implementations of interfaces, we should favor protected
access for methods over private unless it can be shown that
a subclass should by design never have any interest in the
method.
i think it's safe to say that the designer of a framework
can't imagine all the possible uses or extensions of it.
there have been several cases where i've needed to override
jcr-server superclass methods but doing so has caused me to
be dependent on other, til-then private superclass methods.
it's certainly true that angela's recent refactoring has
gotten rid of most if not all of these dependencies from my
code. that doesn't mean the situation won't occur again in
the future. following the guideline i propose above will
make it easier for framework extenders to cope with such
situations.
angela mentioned that there was a specific reason that she
wanted certain CosmoDavResourceImpl methods private. i hope
she'll share that reason. i'm not opposed to making specific
design decisions that make methods private. i just think
that, as a general principle, when there is no overriding
reason to keep a method private, framework classes should
use protected methods in order to allow full flexibility for
extension classes.
