bedeviled mojo slop

Well, the following is my simple test code to finally set straight in my mind what PicoContainer (IoC-Type 3) can do for me. Reading the documentation and most of the blog entries on the site just didn't make things clear. So, the long and short of it is, for me, I register class instances with the container, I ask for an instance of a specific class, and I am returned an instance of that class initialized with all of the proper dependencies. Dependencies are specified as arguments in your constructors.

The code is as follows:

Serializable Component:

package picotest;

public interface SerializableComponent {

    public void serialize(String message);
}

Component A:

package picotest;

public class ComponentA implements SerializableComponent {

    ComponentB componentB;

    public ComponentA() {
        System.out.println("In default constructor for component A");
    }

    public ComponentA(ComponentB componentB) {
        System.out.println("In constructor for component A");
        this.componentB = componentB;
    }

    public void serialize(String message) {
        System.out.println("Serializable component: " + message);
    }
}

Component B:

package picotest;

public class ComponentB {

    public ComponentB() {
        System.out.println("In constructor for component B");
    }
}

PicoContainterTest:

package picotest;

import org.picocontainer.MutablePicoContainer;
import org.picocontainer.defaults.DefaultComponentMulticasterPicoAdapter;
import org.picocontainer.defaults.DefaultPicoContainer;

public class PicoContainerTest {

    public static void main(String[] args) {
        MutablePicoContainer picoContainer = new DefaultPicoContainer();
        picoContainer.registerComponentImplementation(ComponentA.class);
        Object object = picoContainer.getComponentInstance(ComponentA.class);

        DefaultComponentMulticasterPicoAdapter defaultComponentMulticasterPicoAdapter = new DefaultComponentMulticasterPicoAdapter(picoContainer);
        Object multicaster = defaultComponentMulticasterPicoAdapter.getComponentMulticaster(true, true);
        ((SerializableComponent) multicaster).serialize("Hello world 1");

        picoContainer.unregisterComponent(ComponentA.class);
        picoContainer.registerComponentImplementation(ComponentB.class);
        picoContainer.registerComponentImplementation(ComponentA.class);
        object = picoContainer.getComponentInstance(ComponentA.class);

        multicaster = defaultComponentMulticasterPicoAdapter.getComponentMulticaster(true, true);
        ((SerializableComponent) multicaster).serialize("Hello world 2");
    }
}

So, what does this code do? In the first block of PicoContainerTest, I've only registered ComponentA.class with the container. This is not really desirable since if there's any code that depends on methods in Component B, I'm screwed. But I had to test it out to see what would happen. This prints the following:

In default constructor for component A

Why? Because the container does not know about ComponentB.class. In the second block of the test code, I'm testing out the multicast capability. This is interesting because the object returned implements all of the interfaces of components you've registered with the container. That prints the following:

Serializable component: Hello world 1

In the third block of the test code, I've unregistered ComponentA.class and have registered ComponentA.class and ComponentB.class. This prints the following:

In constructor for component B
In constructor for component A

Excellent. Excellent Smithers! I've gotten back an instance of Component A initialized properly so that if any methods in Component A use methods from Component B, we're all good.

What I might like to see ... (If there's a way to do this PicoContainer know-it-alls then by all means, let me know) ... is that if I did not explicitly unregister ComponentA.class, but registered ComponentB.class with the container and then asked for an instance of Component A, I'd like that instance to be the one initialized as in the third block. That is, now the container "knows more" and can give you back a "more proper" instance of Component A. OK, maybe that violates some principle of something.

In any event, this at least cleared things up for me.

I wish I could say better late than never on this article on Foo Camp (which happened in early October of 2003), but I can't. *sigh*