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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
