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
