On Tue, 2004-02-24 at 12:23, Niclas Hedhman wrote: > As Albert wrote; Many of the Avalon developers are very restrictive to > inheritence, as I hope many Avalon users will discover and appreciate sooner > or later. > The bottom-line is; Except for a smaller number of use-cases, inheritence adds > more maintenance problems than it solves. COP is, IMHO, far superior than any > other "code arrangement" that I have seen, and it is almost by definition > incompatible with inheritence. > > I hope I don't sound too harsh, but I am trying to set you back in the chair > so much that perhaps a "wow, what if he is right? Can it really be better > without inheritence?".
Not to put too fine a point on it, that's a bunch of horse hockey. Misusing inheritance can cause problems, yes. However, that's not a reason to throw away the tool. It's exactly the sort of code I mentioned where it's the *right* solution to the problem. The relationship established between a class and its base class by inheritance is a very specific one. It's possible to write code that claims that two classes stand in the "subclass" relationship to one another when they really don't. This is where all the silly arguments about whether "Square" should be a subclass of "Rectangle" and the like come from. But there are very many common situations where inheritance is proper. It's perfectly appropriate that HashMap, TreeMap, and WeakHashMap are both subclasses of AbstractMap. There's a lot of common code that's implied by the Map contract. The same is true of the various subclasses of FilterInputStream or FilterOutputStream. Without inheritance, you get the ugly garbage designs that COM forces on you. Every damn object which has code in common with another is forced to delegate half of its methods to an aggregated partial implementation - or worse, copied from somewhere else. What a mess. Bad design is bad design. You won't improve it by taking away inheritance. You'll only make it worse. The bad designers out there will copy code instead of rigging the aggregation. And there are plenty of ways to misuse COP, as well. I'm heartily sick of the Java community's attitude that tools which are frequently misused should be taken away. To the point of the thread, though, @avalon.dependency out to be inherited. Perhaps with a way to explicitly suppress the inheritance when you don't want it. The dependencies of a base class, when you're using inheritance correctly, *should* be inherited. As should the @avalon.service tags. They're part of the class' contract, which is inherited. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
