avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <aok...@bellsouth.net>
Subject RE: [RT] Notification pattern has interesting effects on IoC
Date Wed, 18 Feb 2004 17:23:55 GMT
> the inform() method for your decoder is doing the transformation of
> event into method call on the 'actual' work interface.
> 
> It might make sense to extract this functionality from all classes that
> do this kind of thing and put it in some common place. I haven't figured
> out how to do that nicely, but it 'feels' smart.

Yes that would be most excellent.  You're setting up the routing so to 
speak - rather the implicit dependencies between these event driven 
components.  If you can centralize the event->method call transformation
logic or event generate it from declarative meta data your really phat!

> I think a subscriber hierarchy will be messy. It seems like you will end
> up with a parallel class hierarchy.

No that actually does not happen with subscriber implementations unless
you're referring to the Event hierarchy.  If you look at the link to the 
paper on the Event Notification pattern in my last email you'll see that
this is a mechanism to control routing.  The subscriber hierarchy is there
also to make things more type safe but I see some of the worries you may
have here myself.

<snip/>

> I split things out somewhat like this in jicarilla atm, but its
> otherwise very similar. I have something like
> 
> interface Decoder
> {
>    Message decode( byte[] buf );
> }
> class DecoderStage extends AbstractStage
> {
>    private Decoder m_decoder;
> 
>    public void DecoderSink( Decoder decoder )
>    {
>      m_decoder = decoder;
>    }
> 
>    Object process( Object event )
>    {
>      EventAssert.assertOfType( event, InputEvent.class );
>      InputEvent a_event = (InputEvent)event;
>      byte[] l_buf = a_event.getBuffer() ;
>      return m_decoder.decode( l_buf ) ;
>    }
> }

Ok I see the stage wraps the Decoder to handle the processing 
(transformation) of the events into calls against the wrapped object.
Does this have anything to do with the Excalibur event stuff?

> so the event handling and the services is decoupled. The disadvantage is
> probably in that you'll likely want a stage, source or sink for each
> service work interface. But OTOH you should be able to use the same
> stage for different service implementations.
> 
> WDYT?

Yes yes I like this a lot.  Still chewing on the idea.  I don't care if I
have to have more interfaces et cetera and do a little more work if the 
Transformation logic and handling is nicely separated out.  IoC remains
intact with my service interfaces not looking like a hairless dog or
featherless chicken - you know what I mean.

- IoC is still in effect
- Clean separation between event handling code and service code
- More readable and you know where to go for event handling issues

I will steal this approach :-) - it is good!  Say if you have the time
give us hand over on the Eve side.  I've started from scratch in building
the server and now it looks like I'll need to make more changes but good 
ones.  Even if you're checking things out to let us know about pitfalls and
keep us thinking it would be great.

Really thanks much,
Alex





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


Mime
View raw message