tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin Sampaleanu <colin...@exis.com>
Subject Re: Use of interfaces ...
Date Tue, 04 Feb 2003 15:02:18 GMT
Generally, I think this would be a step in the wrong direction.

Aside from other considerations, I wouldn't overlook one aspect of 
interfaces, that they make testing (via mock objects, etc.) much easier. 
You can take a piece of code, and when it is dealing mostly with objects 
it talks to via interfaces, very easily stress it outside of its normal 
environment. It's a drag to have to drop something in a web container to 
test it out. If you leave things as an interface, and an abstract class 
that will be used most of the time, when somebody needs to do a test 
they can instead implement only the portions of the interface that are 
really needed for the test.

W/regards to performance, the VM has gotten a lot faster at some 
operations. Reflection for example, which used to be something like 30x 
slower than a normal method call, is only 1.5x slower in the 1.4 VM. I 
would be very surprised if this aspect made much of a difference, 
compared to other things that a Tapestry application might typically do, 
such as hitting a database.


Howard M. Lewis Ship wrote:

>Just a random thought ...
>
>Tapestry uses a few key interfaces:  IComponent, IPage, IEngine,
>IRequestCycle being the main ones.
>
>In theory, you could brew up your own IComponent implementation, not
>AbstractComponent.
>
>Increasingly, though, the framework is making expections that your component
>classes inherit from AbstractComponent.  For example, the new class
>enhancement code expects that fireObservedChange() (provided by
>AbstractComponent) is provided by a superclass.
>
>Every once and a while, I think about scrapping IComponent and IPage,
>renaming AbstractComponent to Component (or TapestryComponent, or
>WebComponent), and likewise of AbstractPage.
>
>There are also theoretical performance improvements in shifting from
>interfaces to abstract base classes.  Method invocation against a class is
>more efficient and easier for Hotspot to optimize than invocations against
>an interface (in fact, there are different bytecodes for invoking a virtual
>method vs. invoking an interface method).
>
>At some point, I'll have an environment where I can do performance testing
>... perhaps I'll match them up against each other!
>  
>



Mime
View raw message