On the coallescing of multiple Foos into a composite Foo, that also does not meet the use cases. Imagine you are pulling in menu actions that will displayed on a toolbar. The UI binds to the list of actions, it doesn’t bind to a compose action. Each action is worked with individually. Composing the action would then mean that the UI sees them all as a single action, when they are not. Now if you are doing a chain of responsibility on the other hand, then having the components as a single would be very nice.

Enumerability, and its combination with Metadata, isn’t a leaky abstraction when the identities of the individual injected components matter to the consuming component. You mentioned coalescing – instead of applying these adapters to the consumer of the coalescer, they’d be used to implement the coalescer in a container-independent way. Likewise for the composite.

As a concrete example, instead of exposing all of the individual “shape renderers” to the different components in a drawing application, they’d use a composite shape renderer that accepted a shape and dispatched it to the appropriate underlying “atomic” renderer. It is the implementation of the composite renderer that needs enough information to correctly dispatch the shape.

Agreeing on small building blocks like these mean that more complex composition patterns like these two you’ve mentioned can be defined in an application-specific way. Deciding on a common specification for implementing these patterns in their entirety would be orders of magnitude harder than the task before us here. (Imagine trying to write a common spec for how rendering an unknown shape would proceed in the above example.)

Regarding ownership/component release – the general problem here is that in order for the container to manage lifetime “for us” it must have some sense of where a Unit of Work begins and ends. Most current approaches require container-specific configuration based on ambient state and application lifecycle events. It is not always possible to associate a unit of work in an application with these.

On Lazy and inheritance – I agree that the transparent proxying approach is nice, but not all services are expressed as interfaces or virtualised ABCs. Providing the transparent mechanism via configuration is a nice addition to a baseline ‘portable’ alternative like Lazy.

Your ideas on expressing metadata selection as a Func/Predicate structure are really interesting – I’m glad you’ve popped up on the CCA forum, this will be a fantastic alternative to consider when we get to selection-from-alternatives

I think some of them are valuable as more explicit dependency relationships, whereas others are important DI Container creation strategies, but not necessarily as explict Adapters. Let’s look at each one:

Func<B>: This is simply an Abstract Factory, which is one of the most important DI patterns available. It allows us to bridge the gap where a consumer needs to create an arbitrary number of abstract instances managed by the container. Some DI Containers can automatically create such strongly typed Factories at run-time based on registered parts and the type of the Abstract Factory, but it would be very valuable if they all could.

Func: This is also an Abstract Factory, but an even more important variation, as it bridges the gap where we need to combine long-lived services (B’s dependencies) with run-time values (X and Y). In reality, we will need Func, Func, Func etc. It would be even more valuable if we could agree on a Common Context Adapter that allows each DI Container to automatically emit an implementation that does this. I have more thoughts on this, but let’s continue that discussion over at the Common Context Adapters project

IEnumerable<B>: This is another common DI pattern, but in many cases I consider it a Leaky Abstraction if a consumer explicitly requests it like this. It would be more correct to simply request B and then configure the container to return a CompositeB or a CoalescingB (both implement B), thus encapsulating the knowledge that there may be more than one. Once again, it would be valuable if a DI Container could automatically emit these. It ought to be doable for Composites, but I’m not sure about Coalescers…

Owned<B>: This one I’m not quite sure of. As a general principle, I consider DI to imply that we are giving up on controlling the lifetime of dependencies, yet here we attempt to do so anyway. It feels like a Leaky Abstraction as well, but I presume that for a long-lived service that consumes short-lived dependencies (created by Func), this provides a mechanism to signal the release of the dependency (and thereby allowing for potential disposal). I have to think about this some more.

Lazy<B>: This can be a valid lifetime strategy, although I consider it a bit of a corner case. I’ve already described my thoughts on this approach here: http://blog.ploeh.dk/2010/01/20/RebuttalConstructorOverinjectionAntipattern.aspx. In summary, I find it valuable if a DI Container supports this lifetime strategy, but I consider it a Leaky Abstraction to take a dependency on Lazy<B>. Rather, Lazy<B> ought to be a lifetime strategy that we can configure in the container so that when A requests B, they really get a Lazy<B> (which means that Lazy<B> must derive from B).

Meta<B>: This is basically just a Tuple, but with a bite more intention-revealing name. Once more, my knee-jerk reaction is that if a consumer requests such a dependency it would be a Leaky Abstraction. A better approach would be to model the dependency either by the Tester-Doer pattern or try to adhere more to the Hollywood Principle. But once again, as seen from the Container’s side, it would be awesome if we could specify complex rules that injects dependencies based on some sort of context. I would rather want to see X expressed in terms of the Specification pattern (basically a Predicate). At this point, we are very close to a parameterized Abstract Factory – it’s Func where S is a Specification.

(BTW, I only realised recently – if the dependency is on IQueryable<Meta<T, TMetadata>>, despite the fact that Meta<T, TMetadata> is not lazy, the appropriate component/s can be selected without instantiating others unnecessarily.)