avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Simons" <leosim...@apache.org>
Subject RE: [FOP Avalonization] IoC the holy grail?
Date Tue, 03 Sep 2002 13:00:28 GMT
> -----Oorspronkelijk bericht-----
> Van: Nicola Ken Barozzi [mailto:nicolaken@apache.org] 
> Verzonden: dinsdag 3 september 2002 11:35
> Aan: Avalon Developers List
> Onderwerp: [FOP Avalonization] IoC the holy grail?
> I'm doing some work on Avalonizing FOP, as it has been 
> decided it's the 
> right way.

great wisdom, you have shown =)

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

Nope. Not everything is a component, or should be. I always suggest
that data representation is not made into components. If your
definition for component is "a passive entity that performs a
specific role", it should quickly become clear that things that
do not perform a specific role should not be component.

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

Are they components? If they are, you should be able to chuck
them into a container easily enough that supports Servicable.
You can also do

	service( ServiceManager sm )

if it really doesn't make sense to use a 'real' container,
but that probably indicates you shouldn't use Servicable

> Should I?

Can't say at all in this case. What do you mean by "project"?

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

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

	ImageFactoryService m_ifs;

	service( ServiceManager sm )
		m_ifs =	(ImageFactoryService)sm.lookup(

	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 =)



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

View raw message