Hi,
At 12:29 19/1/01 +0100, Paulo Gaspar wrote:
>> -----Original Message-----
>> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
>> Sent: Thursday, January 18, 2001 23:04
>>
>> One appropriate question to ask yourself, when comparing, is
>> "what does having 15
>> entry points give me that I cannot get with a single entry point
>> approach"? If
>> there is nothing significant, then it would seem cleaner to rely on a
>> simpler-to-understand approach.
>
>That is a problem also found in several parts of business application
>frameworks - those things that help you building a big User Interface
>to manipulate and extract information from a big Database.
>
>You also find the same questions over GUI Frameworks - like Delphi's
>VCL or Java's Swing. And in database interface libraries...
>
>In all of these you find events (Hooks) named "onThis", "beforeThat"
>and "afterSomethingElse". And all this frameworks are built using
>Object Oriented Programming Techniques.
I think you are mixing concerns here. I have worked with multi entry point
interceptors (what you call hooks) before and I *believe* that there are
different levels of organisation that have to be examined. You mention GUIs
here so I will address them here. For instance consider javas GUI awt.
Under windows it gets it's events from a multitude of different sources
(some are grabbed from eventqueue, others from win32 hooks and others are
application created) then routes them through a central message queue and
central dispatching model. In many ways the way it works is similar to
hardwired valve style implementation. It is only at the upper layers where
it is transformed into the
preReleaseMouseButtonEventHookLudicrouselySizedMethod() and equivelent
postRelease*().
I agree that it is sooooooo much easier on the developer to do things this
way in the common approach. It becomes difficult in *certain* circumstances
but in most cases it is easier.
You will see that moderately complex hand-crafted GUIs also move in this
direction by routing them via a central bus and dispatching them in a more
friendly way higher up in the framework.
The advantage of hooks is also the speed of development - ie it takes about
1/5 of the time to develope a hook based solution rather than a general
solution. The general solution first has to be general and then it has to
layer specificity on top of that (see below) which is even more work.
>The advantage of Hooks is that the programmer is only exposed to the
>very narrow complexity of a very specific event. The framework takes
>care of the rest.
Right but generally the good frameworks go
specificity -> general -> specificty
So your GUI events functionality is provided by classes the extend the base
functionality in a OO way. In the case of Tomcat you would do it
differently - for hook "foo()" you would instead create a base valve
AbstractFooValve and repeat this for all valves. (Yes thats a damn lot of
work!!!)
>When you build your own thing that you put in a logic/data pipe,
>sometimes you have to understand a lot more about the inner working
>of the framework in order not to screw anything.
agreed. Thats why AbstractFooValve is near essential ;)
The only reason to choose Valves is for performance and flexability. You
pay for it in container dev time and initial dev complexity. But if you see
Tomcat4.x still being operational 2 years from release within a wide
variety of purposes then it is well worth it.
I am not saying that Catalinas concept of a valve is completely correct (it
uses the Anti-Pattern Subvertion of Control - yuck !!) but it is definetly
a step in the right direction. Personally if I was doing it then I would
implement Inversion of Control and your valve interface would be as simple
as below but I think Valves as they exist are a step forward thou YMMV.
public interface Valve {
public void invoke(ValveContext context, Request request, Response response)
throws IOException, ServletException;
}
public class MyValve implements Valve {
public void invoke(ValveContext context, Request request, Response response)
throws IOException, ServletException
{
...do stuff with request...
context.invokeNext( request, response );
...dostuff with response...
}
}
Cheers,
Pete
*------------------------------------------------------*
| "Computers are useless. They can only give you |
| answers." - Pablo Picasso |
*------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
