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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
