avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [FOP Avalonization] IoC the holy grail?
Date Tue, 03 Sep 2002 13:23:21 GMT

Peter Donald wrote:
 > Ahh - forget everything I said. Berin said exactly what I wanted to 
say but
 > better! Drat it ;)

Naa, I didn't understand much at first.
Then I read yours, and I still wasn't convinced.
Then I went back to Berin's and understood =:-)

Anyway, my quick comments.

Peter Donald wrote:
> On Tue, 3 Sep 2002 19:34, Nicola Ken Barozzi wrote:
> 
>>I'm doing some work on Avalonizing FOP, as it has been decided it's the
>>right way.
>>
>>We are using already LogEnabled, and now it's time for Configuration,
>>but most important of all, usage of the SourceResolver.
>>
>>Now, I'm dealing with a problem I already had with POI (we want to
>>avalonize it too probably).
>>
>>When we have big object pacakge structures and classes, it becomes
>>somewhat impractical to use IoC.
>>
>>For example, in POI there are tons of classes that represent portions of
>>the OLE2 file format.
>>Shall I have all of these become container-components?
>>
>>Or in FOP: there needs to be an ImageFactoryService, but the problem is
>>that it needs to be used by projects deep in the call stack.
>>
>>How can I make these components serviceable?
>>Should I?
>>
>>It seems that when the model becomes too finegrained, the Avalon
>>patterns become difficult to use.
>>
>>Comments, ideas?
> 
> 
> It is hard to give a good explanation without knowing either system well 
> enough. However I would generally recomend that if it does not "feel" right 
> to do something then it probably isn't. 

:-) I am totally with you on this. It's true in life in general; look at 
the equations of relativity, or even only the old 
earth-center-of-the-universe debacle: when it's cool, it shows, when it 
suffers, it shows.

> Which means you either needs some 
> rearchitecturing of the application or need to not use Avalon at that level.

I was thinking of the latter.

> Let me use the POI components as an example. I know absolutely zero about them 
> so ignore any of the glaring inaccuracies ;)
> 
> The classes in POI represent bits of OLE2 file. Presumably they are passive 
> (ie they just hold data) or they are reactive (they just "react" to method 
> calls on them). In the first case, Avalon interfaces have no place being part 
> of the object. In the second case I would tend to pass the relevent services 
> in via the method parameters.
> 
> So rather than
> 
> OLEThingieMaJig tmj = ...;
> tmj.enableLogging( logger );
> tmj.service( sm ); 
> tmj.doStuff();
> 
> I would do 
> 
> OLEThingieMaJig tmj = ...;
> tmj.doStuff( logger, sm );
> 
> or preferrably
> 
> OLEThingieMaJig tmj = ...;
> MyRequiredService myRequiredService = ...;
> tmj.doStuff( logger, myRequiredService );
> 
> or maybe
> 
> OLEThingieMaJig tmj = ...;
> MyRequiredService myRequiredService = ...;
> try
> {
>   logger.debug( "Pre-doStuff" );
>   tmj.doStuff( myRequiredService );
>   logger.debug( "Post-doStuff" );
> }
> catch( SomeException se )
> {
>   logger.debug( "Somexception occured!", se );
> }
> 
> You will notice that the last version knows nothing about avalon. You will 
> also notice that as I went down through the examples, less and less work was 
> placed on the shoulders of the OLEComponent and more and more work was placed 
> on the shoulders of container of OLEComponents.
> 
> However this may seem like a lot of work - especially if there is no real 
> notion of containers for the objects (or the containers are other 
> OLEComponents).

Exactly!

> In which case I would create a set of active/behaviour orientated classes. 
> Something like OLEComponentVisitor. These "behaviour" components I would 
> strongly recomend use Avalon interfaces if you can.
> 
> So I guess my recomendation would be to separate passive (ie data holding) and 
> active (ie behaviour orientated) objects and restrict your Avalonization to 
> the active objects. If this is not possible for whatever reason I would tend 
> to pass the needed resources into the behaviour bits (ie methods etc).

A kind of command-pattern.

> If that is still not possible then I would recomend creating another API layer 
> for working with the low level components. Perhaps a good idea would be to 
> use something like
> 
> interface OLEContext
> {
>   Object getMyMagicStuff();
>   int getOtherStuff();
>   String performMagic(String someParam);
> }
> 
> OLEComponent.myMethod( OLEContext ctx );

Ah, nice.
A sort of pass the servicemanager-context in with the call.
It reduces the number of parameters and makes the method signatures 
invariant with changes to the servicemanager-context methods.

> And after doing that for low level components would restrict avalonization to 
> high level service orientated/or pluggable components. 

Yup.

> Not sure if that hepled any?

Yeah, thanks :-)

You added the pass-the-service bit that I didn't get from Berin's post :-)

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Mime
View raw message