On Sun, 2004-02-08 at 23:09, Niclas Hedhman wrote: > On Monday 09 February 2004 11:34, Albert Kwong wrote: > > 1. If an abstract class is used to handle > > lifecycle methods for components, the subclass does > > not necessary has these two methods, and thus it would > > be impossible to declare component dependencies. (of > > course empty service() or compose() methods may be > > declared, but that's like cutting toes to fit the > > shoes). > > I think part of the answer is that "many" Avalon developers are generally > against inheritence, and don't think it is a good idea to subclass components > from a general superclass. > > Having the "empty" (more like, super.service() ) is a price considered > reasonable for these "undesirable" patterns.
God, I *hope* that's not the reason. That'd be utterly preposterous. It's perfectly reasonable that a give service interface only makes sense if a particular component is available, and I may need to provide several different specific implementations of the component. An abstract base class is a perfectly natural place to put the common aspects of that implementation. To do it without inheritance is just plain bad design. For example, consider a component that formats data. You have a version to format in XML, and another that formats in CSV. The actual access of the data source, and reading from it and so on, is identical in both versions. It's just a few lines of the actual output code that differs. Javadoc is normally inheritable these days -- if you override a method (or implement one from an interface), but don't provide a doc comment, it will inherit the comment from the base class. Seems like that ought to apply to @avalon tags. The various descriptors ought to be merged for each of the classes in the inheritance tree. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
