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 ;) -- Cheers, Pete ------------------------------------------------------- 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
