ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jon S. Stevens" <>
Subject Re: Did somebody say Shut up and Write? :)
Date Fri, 22 Dec 2000 06:03:45 GMT
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.


> 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 <> 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:
> For additional commands, e-mail:

Scarab -
      Java Servlet Based - Open Source 
         Bug/Issue Tracking System

View raw message