avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [Proposal] ECM / ECS / AbstractContainer
Date Mon, 04 Mar 2002 11:28:29 GMT


> From: Leo Simons [mailto:mail@leosimons.com]
>
> Basically, what you are proposing is to create a hierarchy of
> ECMs/ECS rather than a single-level-deep structure, IIUC. The
> advantage of this is that using a tree instead of a map results
> in better maintainability in larger projects. Right?

That would be one possiblity, and I could make some arguments
for this, but what I want is to factor out the "this component
can have subcomponents" behavior from ECM/ECS. That is the primary goal.

Both ECM and ECS now have a getComponentHandler method, for example.
Both of them implements LogKitManageable, Contextualizable etc. for
the sole purpose of passing on the obtained LogKitmanager, Context, etc.
to the component handlers.

What I want to do is create a common superclass for ECM and ECS
and move that code there.

So to split the questions:

 1) Should the common code of ECM and ECS be factored out?
    This would make it easier to write ComponentSelectors
    and ComponentManagers.

 2) Is it proper for a component to have subcomponents,
    even if that component is not a ComponentSelector?

I'd vote yes to (1) and yes, in some cases, to (2).

> The disadvantage is providing unneccessary functionality in
> simpler setups and degrading performance.

Performance will not be degraded in the current setup. If you
use it, you pay for it, otherwise not.

> You should only break IoC if you really need to.
> Do you?

Well, the jury in my head is out on that one, as well as whether
I am in fact breaking IoC, or just avoiding namespace pollution (roles,
hints) by putting components that I can prove will only *ever* be used by
one component inside that component.

Suppose you have a component:

 <component role="General"
            class="my.generals.Franks"
            use-strategy="my.strategies.Stealthy"/>

So the "General" is set to use a strategy defined by my.strategies.Stealthy,
by instantiating that class and then calling a whatDoIDoNext method on it.

This does not break IoC.

That was how I started. Then I figured that maybe the strategy object
needed to be initialized. And maybe it needed a CM. And a configuration.
And maybe sub-strategy objects.

Finally, I was about to write an entire Avalon lifecycle manager for
the strategy, and since that code already existed in ECM and ECS, well...

/LS


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