I’m not a big fan of named arguments, particularly if I don’t have a compiler: I’ve been bitten too many times in Perl by typoing an named argument. Perl’s error swallowing (e.g. silent conversion of undef to the empty string) makes the situation all that much worse.

Why are none of the cases you’ve described supported through constructor injection?

Maybe I need to clarify my position a bit. I support constructor injection for properties that are mandatory: that is, for properties that are necessary to be set for the object to do its job. Once set, I have no problem with the value being changed (including collections having elements added or removed) — I just don’t ever want to be able to get an object which isn’t usable because it’s partially configured.

Optional parameters, or parameters for which reasonable defaults can be inferred, should be left as accessor properties so that they can be cleanly ignored. I’ve just realized (by meandering blogs) that some people are advocating setting all properties at construction time. That’d be nice if Java was a functional language, but I see where that rapidly becomes a serious pain (imagine trying to programmatically work with BasicDataSource that way).

However, the main limitation of contructor injection in my opinion is that it only supports dependencies that are mandatory, unary and static. When Spring-OSGi comes along, you’re going to have more flexibility in all three of those dimensions: firstly, you’re going to get “nice to have” dependencies, i.e. bean A would like to use bean B if it’s available, but it can still do something useful even when it’s not. Secondly, you might have twenty instances of bean B and A wants to know about them all. Thirdly, you’re going to have beans that come and go, and a single instance of A might need to bind to multiple different instances of B during its lifetime. None of these use cases can be supported with constructor injection.

So, as with most things, constructor injection is nice, but not the solution for everything.