Funny...a good portion of Turbine is implemented this way. :-) Of course Turbine is the wheel (mostly because it came first) and everything else is re-inventing it though. :-)
p.s. If you take the last statement seriously, go for a walk. -jon > > James Duncan Davidson wrote: > > > > > Like I said, I used to use interfaces *everywhere* and staying the heck away > > from anything that exhibited more than 1 level of inheritance -- and even > > that was too much for a while for me. Experience kicked in after a while and > > it became a pain in the ass. And showed that there are big places in the > > world for Abstract Classes and inheritance. > > Interestingly, that has been my own experience as well. > > When the Struts Framework project <http://jakarta.apache.org/struts> first > started, we began with the "pure O-O" approach of interfaces for all of the > core > abstractions. But, as we are approaching a 1.0 release (where you had better > get > really serious about backwards compatibility -- I guess for Ant that will > happen > at the 2.0 level :-) -- it became apparent how risky this strategy is. > > In Struts, the most commonly implemented component is an ActionForm -- > basically, > you've got one of these per input "form" in a webapp. Naturally, we provided > a > convenience base class that implemented a lot of standard functionality that > most > ActionForm bean developers would appreciate. > > But then, it became obvious: if we left ActionForm as an interface, consider > what > happens if in Struts 1.1 we want to add some new method signatures to > ActionForm > for additional functionality. Yes, we can add new default methods to the > convenience base class, but the whole idea of an interface is that we're > granting > *permission* to implement it completely your own way. > > At that point, you look yourself in the face and say "is it worth breaking > every > single implementation by every single user who accepted this permission"? For > people who care a lot about backwards compatibility (count me in that camp), > this > is a huge disincentive to add functionality to your basic components if they > are > based on interfaces. > > If ActionForm is a subclassable base class (as it is now), however, the only > people that get screwed by additions are those who happened to have > implemented > the same method signatures that you are trying to add. You still need to take > this into account, but at least the population of affected users is likely to > be > much smaller than the "everybody" crowd affected by changes to fundamental > interfaces. > > For everyone else (and this tends to be a very large majority), the change is > transparent, as long as the default behavior of the new functionality remains > the > same as what you had before. > > As a result, I've grown to prefer base classes that can be subclassed, rather > than > interfaces, to expose the functionality key components. I still like > interfaces > to define optional behaviors that might be implemented by a large variety of > object types, but tend not to like them as much for the key architectural > concepts. > > Craig McClanahan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Scarab - Java Servlet Based - Open Source Bug/Issue Tracking System <http://scarab.tigris.org/>
