Peter Donald wrote:
> On Fri, 18 Jan 2002 13:39, Ryan Shaw wrote:
>
>>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?
There are different things you have to concider. Here is a
clear example of breaking IOC:
1) A Container exposes a reference to itself globally. (i.e.
through a static accessor)
2) A Container passes itself as a reference to its children.
It is less clear when two objects may either be considered peers
or children.
In the case of the ThreadPool, the WorkerThreads are peers of the
ThreadPool, and therefore they can share enough information with
each other to work properly. The Child in this case is the
Executable or the Runnable that is run by the WorkerThread. In
this case, the WorkerThread is considered a peer/utility class,
and the reference to the Pool is encapsulated--keeping it safe
from the children.
In the ContainerManager code I am putting together, the
ContainerManager is concidered a peer to the class that uses it.
For instance, the system can be originated from a servlet, the
command line, or even another container. The Servlet class is
the peer of the ContainerManager code--even though the
ContainerManager directly manages the instance of the Container
(which may be a Component itself).
The Container is considered a child of the ContainerManager, and
any references to the ContainerManager are done through it's artifacts.
The artifacts are the LoggerManager, the RoleManager, the ComponentManager,
the to be developed CommandManager, etc. All of those instances are
directly managed by the ContainerManager, and the Container only
gets references to what it needs to get the job done.
So, the general rule of thumb is that it is OK for peers (classes
that operate cooperatively) to share references to each other--as long
as the reference is never exposed to the child. All children should
never be passed a reference to the parent.
In the case of something less clear like the JdbcDataSource component,
where the Connection object is both a peer to the JdbcConnectionPool and
a child object depending on the context of the view, you have to maintain
everything in that context. For instance, there is no getPool() method
on the JdbcConnection object. The reference is maintained internally
so that the connection can be returned to its pool. However the interface
(both public and protected) never allows access to the pool by any
client.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
