ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <dun...@x180.net>
Subject Re: Did somebody say Shut up and Write? :)
Date Thu, 21 Dec 2000 08:41:09 GMT
On 12/20/00 2:09 PM, "James Cook" <jimcook@iname.com> wrote:

> I didn't note that "Ant spends cycles analyzing the dependencies between
> targets" and when I mentioned anything about efficiency, I am *not*
> referring to execution performance, but rather clean and simple code.

Efficiency as stated in your proposal would indicate otherwise.

> Hmmm...only 3 1/2 years?

At Sun working with the architects of the language and the platform. I've
been programming in Java since before JDK 1.0 shipped.

> I agree that interfaces are an appealing design choice, and I strongly
> disagree that it "doesn't always work out so well in practice". I suppose it
> doesn't *always* work out so well when you try to design interfaces at too
> high a level. Look at the List or Collection interfaces in the Java
> Collections class. They are perfect examples of interfaces defined at the
> right level.

Right. I didn't mean to blanket it with *always* work so well in practice.
They however, need to be at the right level. When we did the Java Server
Toolkit, we did all sorts of generalizations. More and more starting with
HTTP and working to much different protocols such as FTP, DNS, and DHCP. And
at some point we generalized most of the way back to java.net.Socket. And we
spent quite a bit of time, effort, and money doing so.

>> Once you code
>> an interface, you should *not* touch it. It's a published thing
>> that, if you
>> change it, breaks other things in subtle and nasty ways.
> 
> Welcome to one of the commandments of object-oriented programming. Thou
> shalt not change interfaces. This doesn't preclude you from extending
> interfaces and/or augmenting methods to an already-defined interface. Hence
> the need to define interfaces at the "appropriate" level.

That¹s what I said. :) Though maybe not so well.

>> Also, in *so* many cases that I've used interfaces in to allow all sorts of
>> implementations behind -- I've found that there have been 1, maybe 2
>> implementations of those interfaces. And for that you pay in extra code,
>> extra class load time, etc.
> 
> I can't believe that I am debating the merits of the interface design
> pattern with someone who has spent the last 3 years developing APIs that are
> essentially based on the same pattern.

That should tell you something. Yes interfaces make sense at some levels.
And they don't make sense at all levels -- or even most. It so happens that
the APIs that I've helped to develop *do* fall into that territory which is
one of the reason that they were good candidates for Java Platform APIs.

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.

> I agree with you that interfaces are good (or not bad as you put it). The
> examples that you cite are APIs, although those APIs do leverage the
> interface design pattern very well. So, tell me again, why shouldn't Ant
> *core* be based upon the same common strengths that the interface pattern
> gives all of these other rock-solid APIs?

When there are going to be 1 or 2 implementations max -- interfaces are
overkill and quite possibly burdensome later on. When there is quite a bit
of functionality that can be performed, then abstract classes make sense.

Look at the Servlet API even -- to take an example of this -- we have the
Servlet interface, then we have GenericServlet that implements that as an
abstract class, then we have HttpServlet that implements that as an abstract
class. Practically every servlet in the world extends HttpServlet.

(The reason that there's that extra layer, btw, was that it was thought that
there would be other kinds of servlets -- but it turns out that servlets are
thoroughly rooted in the paradigm of a text-based request-response protocol,
which means HTTP and various things built on HTTP like DAV. Oh well.)

So, why isn't HttpServlet an interface.. That has to do with 2 things -- 1)
it provides a heck of a lot of functionality such as looking at the request
headers and determining if the HTTP request is a GET, POST, PUT, or
something else -- then calling the appropriate functionality of the servlet;
and 2) the fact that most of that functionality was added after the Servlet
interface was pretty much locked, but it needed to be there to a) provide
keep alive benefits and b) help Servlet writers organize their code
effectively.

In retrospect, things would have been different if we were designing the API
now with what we know and what changed over the past 4 years or so. However,
that's how it landed -- in part because of history, and in part because
abstract classes are just damned useful in this case.

You bring up Collections. I have to note that Josh had the advantage of
modeling on data structure concepts that have been in the process of taking
form in our collective conscious for loads of years (decades). It's a lot
easier to say "We know how a Set works" when it's been proven over such a
long time. Just like most people would agree that a Unix system has a
/usr/bin and a /usr/local/bin and what `ls` and `cat` do.

Java based build tool semantics have been around for, oh, about a year now.
At least in public. We've got a long way to go before those are nailed.

.duncan

-- 
James Duncan Davidson                                        duncan@x180.net
                                                                  !try; do()


Mime
View raw message