RE: [picocontainer-dev] PicoContainer API enhancement

Hi Nick, 



________________________________

	From: Nick Sieger
	Sent: Monday, March 27, 2006 11:29 PM
	Subject: [picocontainer-dev] PicoContainer API enhancement
	
	
	I thought I'd propose a small API enhancement that I found myself coding up during my usage of Pico.  I tend to prefer standalone pico with a builder-style pattern that has a single class responsible for populating the container with its components and then fetching a main object instantiated by the container. 
	
	As soon as you have more than a handful of components in your container, code to do this becomes rather ugly -- you basically have a huge block of container.registerComponent/container.registerComponentImplementation statements.  I wanted something more declarative. 
________________________________

Yes, I've detected the same. Though I've started to use the XML builder of Nano for better configuration lately.

________________________________
	
	Basically, this amounts to applying the parameter object pattern to the various PicoContainer.register* methods.  Instead of:
	
	
	MutablePicoContainer pico = new
	 DefaultPicoContainer();
	pico.registerComponentImplementation(Boy.class);
	pico.registerComponentImplementation(Girl.class);

	You get something like:
	
	
	MutablePicoContainer pico = 
	new DefaultPicoContainer();
	ComponentMetadata[] components = new ComponentMetadata[] {
	    new ComponentMetadata(Boy.class),
	    new ComponentMetadata(Girl.class)
	};
	pico.register
	(components);
________________________________

IMHO this does not justify an API change, but read-on.

________________________________

	You can cover all the various register* methods in PicoContainer simply by adding constructors to ComponentMetadata.
________________________________

Well, the only really used method is pico.registerComponent(...). You might not even support different factories - not just the two ones internally used by DPC.

________________________________
	
	This probably does not seem like much gain (in fact for the example it increases LOC), but it lets you move the component metadata declaration somewhere else, e.g., a static field declaration.  For me, separating that data from the code that constructs the container is a fairly big maintenance and readability win.
	
	It also takes the concept that a component is not just a class, but possibly a class plus some wiring parameter hints, or perhaps a custom CA, and gives that thing a name.  It lets you aggregate that information and pass it around.  It seems like a useful abstraction to have in the container. 
	
	If you're hankering for a larger, more concrete example, let me know and I'll put one together.
	
	Cheers,
	/Nick
________________________________

For me this sounds as an useful add-on to pico-gems. All you need is a helper function like Builder.register(MPC, CM[]) that iterates over the array and calls mpc.registerComponent().

WDYT?

- Jörg