Variation on container dependency anti-pattern

Note that the 'testShirtQuality2' test case does not work in the current codebase without the attached patch. What I am trying to illustrate is a way to soften the container dependency by defining a focused interface and having the container implement that interface.

Also, I like the idea of managing component dependencies by having parent containers (in this case the domain object container) manage components in a conceptually separate application layer that are dependencies for components in child containers (the service component container). Is this an appropriate way to structure a layered application?

Nick,

I'm stuggling to understand what you are requesting here.

Could you work over the test cases and change the method names from

testShirtQuality1 (and alike)

to

testFooExceptionNotThrownForPerculiarCurcumstances

( refer the lessons learned from Agiledox - http://joe.truemesh.com/blog//000047.html )

Also, as a note, it is very unusual to extend DefaultPicoContainer for a business purpose (TShirts), rather that wrap/contain an instance.

Thoughts?

• Paul

I'll have a look at my test case again, rename the test methods and see if I can refocus the test based on my thoughts at the time. Should be able to have something for you to comment on in a couple of days. Thanks for taking an initial look.

Hey Paul,

I think I've got this sorted out pretty much. I've attached a new streamlined test case which turned out to be just an exercise in pico wiring logic. Two tests in the previous test case turned out to be duplications. If you see any value in the test case (either as an example or as part of the test suite) feel free to adapt but otherwise it's probably superfluous.

Let me see if I can explain my thinking. What I was originally shooting for was to use a picocontainer to manage/instantiate persistent objects or domain objects, but I wanted to put a pretty face on it (ShirtFactory) so that clients that wanted to look up a particular instance would have a properly typed method for doing so. Components that need to be able to look up shirts (the ShirtManager) wouldn't have to depend on the container, they could simply depend on the lookup interface. But as you point out it introduces the anti-pattern of extending DefaultPicoContainer in order to introduce this lookup interface on the container.

What I ended up doing in the revamped test case is make the ShirtFactoryImpl a component inside of a DefaultPicoContainer that depended upon it. So in effect I've traded one anti-pattern for another, and neither solution feels quite right.

I still haven't resolved for myself whether domain objects should live in a picocontainer – it seems to me that if domain objects don't either have the behavior on their own classes or through close neighbor references then they're probably doing too much or don't have enough behavior close to the object's data (e.g., if they depend on a service component). Fowler talks about a "Anemic domain model" and I think this could be a symptom of that. If this is the case then maybe picocontainers are not needed to wire domain objects together.

In the back of my mind I'm trying to envision using picocontainers to represent different layers in a layered architecture. One container to hold domain objects (but maybe not based upon the previous paragraph), one to hold service components, one to hold model/view/controller components, etc. and the layered containers would be linked via the DefaultPicoContainer's parent link. This whole stack of containers would then be built/composed and placed into the servlet hierarchy (in the case of nanoservlet) or possibly wired by a groovy script (in the case of nanoweb) but I haven't taken this past the conceptual stage yet.

Any thoughts?

Cheers,
/Nick

Hi Nick,

can we close this issue? Although the injection of a PicoContainer is in general an anti-pattern, it might be used for such kind of service levels as you describe. Personally I've used a hierarchy of Picos myself wrapped by an service interface that is implenented by my main class, that also has the start-up code and does the wiring.

But we might continue with this discussion on the list and just close the issue here.

• Jörg

Joerg, yeah, please go ahead and close this. I was just bouncing around some ideas but since have come to agree with Paul's point that extension of DefaultPicoContainer is not the right way to go.

Closed at request.