The ComponentMulticasterSay you have an interface: public interface Peelable { void peel(); } If you have a container that is full of objects that are Peelable: pico.registerComponent(Apple.class); pico.registerComponent(Pear.class); pico.registerComponent(Grape.class); pico.registerComponent(Orange.class); pico.registerComponent(Potato.class);
It would be useful to tell the container to
peel() them all for you. What you would like to do here is treat the whole container like a Peelable, so that when you call peel() on the container it calls peel() on all the individual components for you. Pico does let you do this: Object multicaster = pico.getComponentMulticaster(); Peelable peelable = (Peelable) multicaster; peelable.peel(); In fact Pico gives you even more than that, because the Object that getComponentMulticaster() returns implements all the interfaces that your components implement . What this means is that if one of your components (say Potato.class) implements a different interface (say Mashable) then you can call that interface in the same way: Mashable mashable = (Mashable) multicaster; mashable.mash(); Of course the mash() method is only applied to any components that implement the interface Mashable. So you can't accidentally mash() an Apple or an Orange. Advantages of the component multicasterTotally decoupled lifecycle methods are possible, because PicoContainer will generate a proxy for any interface even if it is in a package that PicoContainer knows nothing about. Competing / complementary lifecycle patterns can be implemented without compromising PicoContainer's simplicity. In fact PicoContainer can support multiple lifecycle implementations at the same time. Interface methods can throw Exceptions that are checked and domain specific. Again, PicoContainer doesn't need to know. Interfaces are strongly typed, not breakable as in reflection. |