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