cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: protected vs private instance members (in Woody)
Date Sun, 06 Jul 2003 20:23:26 GMT
Carsten Ziegeler wrote:

>Bruno Dumon wrote:
>>Hi Carsten,
>>I saw you changed some instance members in Woody classes from private to
>>protected. I used to have the habbit of making everything protected by
>>default, with the reasoning of making classes easier subclassable in the
>>future. Woody was the first project I tried to do it the other way
>>around: make everything private by default, and see how quickly that
>>would bring me into troubles.
>>I'm now wondering if the changes you did to Woody are simply part of
>>applying some general design principles or if you came into trouble
>>because of private members? Or to put it in another way: do you think
>>instance members should always be made protected by default?
>Yes, at least in this case. Now usually I think the separation between
>private and protected should be used. But in open source development
>I now tend to make nothing private, because those things that the
>developer thinks should be private could not be used by others using
>this class for whatever reason. So I thing making things protected
>instead of private doesn't really hurt but also empowers the open
>source development a little bit more.
>In this particular case I had the need to change one instance variable
>which I currently don't remember anymore (ComponentManager perhaps)
>and then I started changed everything that came across my eyes.
>I hope this makes sense :) if not at all, we can revert it.

Declaring protected members defines a contract between a class and its 
subclasses. Although this may ease the writing of these subclasses, and 
as such is convenient in the same module, it may break "far" classes if 
the implementation of the class changes.

And as writers of subclasses tend to use all that is available, this 
means that changing a class member may break code that's not in Cocoon's 
CVS. Opensource is also about providing stable contracts...

The convention widely used by Avalon, which is to declare protected 
accessors (i.e. "getLogger()") seems a good choice, as it doesn't hide 
those members that may be of use to subclasses (and only these ones), 
and at the same time protects from implementation change.

A good solution may then be to declare members with package level access 
(no modifiers) and provide protected accessors for members whose use is 
allowed outside the module ?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message