Drew,
Well articulated.
Yes, well said.
What I see in the article is an attempt to regain a sense of control in an IoC based system. The notion of separating the structural aspect of IoC wiring by placing structural interfaces as an inner element seems to be an attempt to reign in the "auto-wiring" capability. Maybe I'm missing the point, but it seems to me that this is an attempt to add complexity to solve the problem -- which to me is solving the problem the wrong way.
I have to agree. There would almost certainly be situations where the solution in the article
would lead to *more* complexity due to the author's reliance on a single interface to
express all injected dependencies. This seems to imply that one would be forced
to create some very complex combinations of interfaces.
Perhaps another way that the problems described in the article could be solved
is for the language syntax of a Java class, itself , to be able to express its
dependencies in some manner. This could be succinct and checkable at
compile time.
Just off the cuff, something like:
public class MyBusinessObjectClass {
private ioc MyDataManager dMgr;
}
or we could use something akin to annotations in Java 1.5.
I await comments from those more expert in IoC.
Randy
