jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Moseley <...@osafoundation.org>
Subject Re: checkins to jcr-server
Date Thu, 08 Dec 2005 21:01:56 GMT
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 

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 

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.

View raw message