cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject RE: protected vs private instance members (in Woody)
Date Tue, 15 Jul 2003 13:33:45 GMT
On Tue, 8 Jul 2003, Carsten Ziegeler wrote:

> Vadim Gritsenko wrote:
> >
> > Carsten Ziegeler wrote:
> > <snip/>
> >
> > >I hope this makes sense :) if not at all, we can revert it.
> > >
> >
> > Not exactly; see Sylvain's response and in addition to it please recall
> > a vote about flow model "add only very necessary things instead of
> > adding all and everything you can think of" (majority agreed with the
> > vote). Parallel between this flow vote and java private/protected
> > members is easy to see: have everything private and open up only very
> > necessary stuff. And, preferably, open up via accessor methods.
> >
> This is really an interesting topic to discuss :)
>
> Now, I don't agree :) I think the contract we define is based on
> Interfaces and perhaps on abstract implementations, but not on
> concrete implementations. You can't guarantee that an implementation
> does not change over time.
>
> Some examples: assume you use an int as an instance variable and
> change it later on to an object (Integer). Now, it's regardless
> if you make the variable private and have a getter method or
> did make it protected.
>
> Or assume, we change from Composable to Serviceable which is a very
> legal change for an implementation. Even a getter method for the
> component manager does not help as when implementing Serviceable
> you don't have a component manager.
>
> So, I think implementations can change incompatible over time and
> if someone relies on the implementation he has to change its
> implementation as well. The contracts (like the above mentioned fom)
> are defined by interfaces.

I'd like to suggest reading "Effective Java" by Joshua Block. Especially:
Item 13: Favor immutability.
Item 14: Favor composition over inheritance
Item 15: Design and document for inheritance or else prohibit it

It clearly shows the danger of uncontrolled inheritance if you don't
specifically design for it.

Giacomo

Mime
View raw message