avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: Silk == More Seda Extractions
Date Mon, 04 Feb 2002 09:22:16 GMT
On Mon, 4 Feb 2002 06:12, Berin Loritsch wrote:
> >>The general concept is that a Stage consists of the Component itself
> >>(handles the logic of the stage),
> >
> > runaway! runaway! runaway!
> >
> > Can't we use delegation instead ? ;)
> What are you talking about?  A Stage is a Component in the SEDA
> architecture.

You suggested that the Stage ISA EventHandler.  Haven't looked at the code 
but thats not how I would design it. I would have the Stage contain a 
reference to the EventHandler. I tend to prefer BlackBox frameworks over 
whitebox ones and thus try to avoid extension via subclassing.

> >>My connundrum is trying to come up with a way to cleanly tie an
> >>EventHandler to a Stage.  Should the stage implement EventHandler, should
> >>the configuration file manage the class to be invoked, or should there be
> >> a getHandler() method?
> >
> > How about another interface "EventHandlerFactory" that is responsible for
> > creating event handlers or something ? That way any strategy could easily
> > be implemented by implementing a different EventHandlerFactory object.
> No.  That is not it.  A Stage in essence *is* an EventHandler.  I would
> prefer for stages to remain ThreadSafe, the current design allows for
> this, and the "EventHandlerFactory" is too much overhead for not enough
> problem.  My issue is reconciling the Block Concept to the Stage
> concept.  All Stages have the same interface, which allows the
> processing to be done incrementally.  Blocks have discrete interfaces,
> which represent specific units of work.

I understood what you were saying and still think what I was saying holds 



To fight and conquer in all your battles is not supreme 
excellence; supreme excellence consists in breaking the 
enemy's resistance without fighting. - Sun Tzu, 300 B.C.

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message