[From nobody Fri Aug 6 17:05:26 2004 X-Mozilla-Status2: 00000000 Message-ID: <3A4308C0.C70459F1@collab.net> Date: Thu, 21 Dec 2000 23:54:40 -0800 From: Jason Hunter <jhunter@collab.net> X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: JDOM Interest <jdom-interest@jdom.org> Subject: Interfaces vs base classes, in Apache Content-Type: multipart/mixed; boundary="------------AE47AD656CC87B8D92976592" This is a multi-part message in MIME format. --------------AE47AD656CC87B8D92976592 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit >From the Apache Ant mailing list, from the lead developer of Tomcat and Struts. -jh- --------------AE47AD656CC87B8D92976592 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Delivered-To: jhunter@collab.net Return-Path: ant-dev-return-8269-jhunter=collab.net@jakarta.apache.org Received: (qmail 2298 invoked from network); 22 Dec 2000 05:08:10 -0000 Received: from locus.apache.org (63.211.145.10) by laswell.collab.net with SMTP; 22 Dec 2000 05:08:10 -0000 Received: (qmail 38118 invoked by uid 500); 22 Dec 2000 05:08:05 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk Reply-To: ant-dev@jakarta.apache.org list-help: <mailto:ant-dev-help@jakarta.apache.org> list-unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org> list-post: <mailto:ant-dev@jakarta.apache.org> Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 38082 invoked from network); 22 Dec 2000 05:08:02 -0000 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> X-Mailer: Mozilla 4.76 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en 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 X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N X-Mozilla-Status2: 00000000 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: ant-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: ant-dev-help@jakarta.apache.org --------------AE47AD656CC87B8D92976592-- ]