avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: Inversion of Control Question
Date Sun, 20 Jan 2002 04:00:35 GMT
On Fri, 18 Jan 2002 13:39, Ryan Shaw wrote:
> My coworkers and I are just starteing to get heavily
> involved in using Avalon. We understand the existing
> packages pretty well, but there are still some conceptual
> issues we are struggling with.

Theres still some issues I struggle with too ;)

> For example, suppose that the ThreadPool implementation
> in Excalibur scratchpad extended SoftResourceLimitingPool
> (it doesn't, but for the sake of argument suppose it did).
> Then when it created new WorkerThreads it would pass
> itself as a reference so that threads could put themselves
> back in the pool when they finished tasks.
> Does this break IOC, because a container (the pool) is
> passing a reference to itself to the things it is
> managing?

Yes and no. If the child got access to the parent through an interface (like 
PoolContext or something) then it probably wouldn't be considered to be 
breaking IOC. At a later stage the implementer could choose to create a new 
object "DefaultPoolContext" that implemented the PoolContext interface. And 
this DefaultPoolContext object could choose to create the support 
functionality for container differently.

Essentially IOC is aimed at providing this flexibility and ease of software 
evolution. If you had directly bound to the implementation rather than an 
interface you would loose this ease.

However in this particular case I would not to choose to view the 
Pool->Thread relationship as Container->Component. There is most likely only 
going to be one implementation of the Component and thus the extra complexity 
added by looking on it as a Container->Component relationship is not really 

> If these examples don't break IOC, please explain why. If they
> do, please explain when it is okay to break IOC and when it
> isn't.

We break IOC in a couple of places. 

* If it is unlikely to have lots of different types of components in container
* If you are unlikely to need to need to provide the component with alternate 
implementations of resources (ie Logger/ComponentManager etc)
* the cost of implementing IOC is high

then we tend not to do it.

For example. Where we have implemented i18n in some of our components you 
will see something like the following at the top of the class.

    private static final Resources REZ =
        ResourceManager.getPackageResources( DefaultApplication.class );

This breaks IOC and if we were going to implement IOC fully then we would 
have something like a 

interface Resourceable
  void setResources( Resources rez );

interface that we use to provide the component with its i18n resources.

However as we don't need that functionality (we assume the whole application 
is executed in one locale) and are unlikely to need it in the future we don't 
IOC it. 

How far you go with IOC is really dependent on your domain and the relative 
cost vs benefit ratio. Personally I consider Composable and LogEnabled the 
"must have" lifecycle stages but I have implemented alternative strategies or 
hardwired other resources (such as i18n) in the past..

> Thanks for any light you can shed on this.

Im not sure I did that but feel free to try and get me to clarify anything if 
it is not clear.



"The fact that a believer is happier than a skeptic is no more to the
 point than the fact that a drunken man is happier than a sober one.
 The happiness of credulity is a cheap and dangerous quality."
        -- George Bernard Shaw

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