Discuss refactoring than enables decoration of comp registration

So I did some UML and checked it against the code and found it was
impossible to implement . The wonderful abstract world of boxes are
lines. So I did a spike first to see where that would get us. I attach
code and a test case which illustrates the point, but I also attach some UML
(as a Poseidon project), although I doubt its value.

In short though its now possible to chain ComponentRegistrar impls to add
behaviour as follows:

final InputSourceComponentRegistrar registrar =
new InputSourceComponentRegistrarImpl(
new StringBasedComponentRegistrarImpl(
new LogEnablingComponentRegistrar(
new DefaultComponentRegistrarImpl())
));
final ExperimentalPicoContainer container = new
ExperimentalPicoContainer(new DefaultComponentFactory(),registrar);
registrar.registerComponents(new InputSource(new
StringReader(xml)));

LogEnablingComponentRegistrar does this:

public void registerComponent(Class type, Class impl) {
final Class firstParameterType =
impl.getConstructors()[0].getParameterTypes()[0];
if (firstParameterType == Log.class)

delegate.registerComponent(type,impl);
}

So this allows me to configure this component:

public LoggableMockComponentImpl(Log log, int port) {
this.log = log;
this.port = port;
}

with this XML:

"<components>" +
" <component
class=\"picocontainer.experimental.ExperimentalPicoContainerTestCase$Loggabl
eMockComponentImpl\">" +
" <param
type=\"java.lang.Integer\">12345</param>" +
" </component>" +
"</components>";.

There is no mention of logging, since its inserted as a decorator.

The enabling interface for all this is:

public interface ComponentRegistrar {
public void registerComponent(Class type, Class impl);
public ComponentSpecification []getRegistered();

public void addParameterToComponent(Class componentImpl, Class
parameter, Object arg);
public List getParametersForComponent(Class componentImpl);
}

ExperimentalPicoContainer is copy of HierarchicalPicoContainer but with all
the registration stuff delegated to a ComponentRegistrar instance.

Few of things about this:

• It means we can insert all the check methods (like checkConcrete etc)
  into the decorator chain instead of hard coding them into a default impl, if
  we want to. Additionally, PicoContainer implementers now have a means of
  inserting their own check methods
• It keeps ExperimentalPicoContainer small and focussed (I did not clean it
  up as much as possible in the attached code).
• If you dislike the fact that registration is on a ComponentRegistrar
  instance instead of on a PicoContainer instance, we can use Chris' trick of
  providing an "as" proxy generation method on the container.
• If the number of potential instances is considered too large, we can
  provide classes that bundle them sensible into "families".

Anyway, let me know what you think. It might not be perfect, but I think
its something we should head in this direction.

Cheers,
Mike.

PS There is one more refactoring similar to this related to storage of
component instances, but its probably too early to extract it yet.