Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <3A42DE36.834C0A4F@eng.sun.com>
Date: Thu, 21 Dec 2000 20:53:10 -0800
From: "Craig R. McClanahan" <Craig.McClanahan@eng.sun.com>
MIME-Version: 1.0
To: ant-dev@jakarta.apache.org
Subject: Re: Did somebody say Shut up and Write? :)
References: <B6670224.D7A0%duncan@x180.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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