Greediest Constructor, Right?

Feb 27, 2008 at 6:30 PM
I just wanted to double-check something I heard, but have not had a chance to go code spelunking to verify.

Unless I specify a particular constructor as my injection constructor, Unity will look for the constructor with the most parameters it can satisfy ( greediest constructor ) to use as the injection constructor, correct?

Oren ( Ayende ) had said this in his blog in response to someone quoting me about using the greediest constructor:

"Re: Selected Ctor
It selects the ctor with the most params, but that is different than the greediest ctor.
The greediest ctor is the one that all its dependencies can be resolved from the container.
Unity doesn't even have this concept." - Link


Unity definitely chooses the greediest constructor and not the constructor with the most params, correct?

Thanks,

Dave
Feb 27, 2008 at 7:15 PM
Edited Feb 27, 2008 at 7:20 PM
Hi David,

We're having a vocabulary issue here. Since the 1st drop, when you do NOT specify an injection constructor using the attribute, Unity chooses the ctor with the MOST params. Some of us (including me) said this was called being the greediest.

Unity as it is right now has NO easy way of telling whether a dependency can be resolved or not. And when you think about the fact that Unity is optimistic and believes it can build anything, there is no such thing as "dependencies that can be resolved". Every concrete type can be built (in theory). Of course, interfaces are a totally different beast.

So Oren is right saying it isn't supported per-se right now.
Feb 27, 2008 at 8:01 PM
Thanks for the clarification, Francois.

I can now see where the line between "greediest" and "most parameters" can be blurred given that Unity will create objects not in its container.

Regards,

Dave
Feb 28, 2008 at 3:31 PM
francois,
Most common scenarios for IoC call for using interfaces. It simplifies development, make mocking easier, introduce isolation and make me a coffee.

Right now Unity create invalid objects.
Feb 28, 2008 at 4:03 PM
Oren,

I agree, I'm all about interfaces. I was just expressing the facts.

However, I think there is much more than interfaces to IoC. I treat configuration as a dependency, hence, I inject all my configuration inclusing dates, paths and other value types.

What's important to me is there are plenty of extension points in the the Unity model to provide such "greedy" capability even if it isn't built-in at this moment. We only had 1 CTP so far.

I think we got all the right abstractions at the right place. All we're really missing is something to expose buildKey mappings.

Then, it's just a matter of creating a new IConstructorSelectorPolicy implementation for "greediest" instead of "longest" ctor. I'm just waiting for UnityContrib to come to life...

Thoughts?
Feb 28, 2008 at 5:51 PM
I'd have to agree with Francios on this one. I've got some scenarios where I need to insert value types or concrete classes simply because I can't add an interface given the current architecture. Is that the perfect way, no, but re-engineering some of these points are less than trivial. I like the "greediest" approach even if it is implimented as an extension. The "longest" constructor definately makes sense from a "ease of resolution" standpoint, but I think there will be cases where the items I'll be constructing will only have say 2 of 4 arguments and can still be built correctly.
Feb 28, 2008 at 6:58 PM

Ayende wrote:
francois,
Most common scenarios for IoC call for using interfaces. It simplifies development, make mocking easier, introduce isolation and make me a coffee.

Right now Unity create invalid objects.


If you're referring to the "returns null if can't resolve" behavior, that was fixed in the latest drop.
Feb 28, 2008 at 10:24 PM
That is good to know, Chris.
Does Unity have introspection now?

Francois,
Yes, of course, I use the container as a central location to build component. Which means that everything goes there, from file path to URL.
That still doesn't mean that you don't get interface for most things.
To be rather more precise, you use interfaces for dependencies, and use concrete types for configuration.