Re: protected vs private instance members (in Woody)

[Christopher Oliver]

I personally think implementation inheritance is a Bad Thing (TM). At my 
company we have a rule that disallows all use of implementation 
inheritance between modules. If module B depends on module A then A must 
provide _intefaces_ that B depends on. This creates a stable contract 
between modules that doesn't require recompilation between changes to 
the implementations.  And changes to the implementation of A can't break 
B. The same code reuse provided by implementation inheritance can be 
also be achieved through delegation and callbacks. We do allow 
unrestricted implementation inheritance (just for convenience) within a 
module, however.

My $0.02,

Chris

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?