Leo Simons wrote:
>>-----Oorspronkelijk bericht-----
>>Van: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] 

...
>>It seems that when the model becomes too finegrained, the Avalon 
>>patterns become difficult to use.
>>
>>Comments, ideas?
> 
> 
> Especially when dealing with existing systems, this can become a
> problem. Most programmers maintain some kind of clean organisation
> at the coarse level and then 'mess up' further down the road. In
> order to do effective IoC, you first need good SoC.
> 
> Not being familiar with POI or FOP internals, I can't really do
> a good analysis here. I'd suggest doing avalonization of the
> coarse components first (ie what you would make into 'blocks'),
> maintaining the 'lack of rigid structure' in the finer-grained
> subsystems. It might not be beneficial at all (or worth the effort)
> to avalonize these projects completely.

What I have experienced in the logging effort.
We tried to pass loggers round using the object hierarchy - please 
forgive me! ;-) - and you can imagine how it went.

We now use a static logger, using our own Facade on top of commons logging.

In this way via a system property it's easy to enable simple system.out 
or use commons logging, and remaon separated from other logging stuff in 
the system.

> If you end up with lots of really small components that (for
> example) all depend on an ImageFactoryService, it probably makes
> more sense to have something like
> 
> ImageCreatorRegistry
> {
>       ImageFactoryService m_ifs;
> 
>       service( ServiceManager sm )
>       {
>               m_ifs = (ImageFactoryService)sm.lookup(
>                               ImageFactoryService.ROLE);
>       }
> 
>       ImageCreator getImageCreator(ImageCreator.ThisKindPlease tkp)
>       {
>               return new ImageCreator( m_ifs, tkp );
>       }
> }
> 
> though the above makes no sense at all to me (no idea how what code
> uses what kind of factory to do something) it isn't a violation of
> IoC =)

Well, it's a factory.

The problem is that using FOP in a server environment, each instance 
needs to have its own resolving strategies.
So I would ask for a ImageCreator via a ImageCreator.ThisKindPlease.

I am actively asking for a specific kind of ImageCreator, which means 
that the registry needs to be smart...

Again a third option, thanks :-)

-- 
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]>

Reply via email to