[filpen]

Thank you for clearing that up, much appreciated.

I also noticed that most of the time the container tends to be used as a Service Locator indiscriminately around the code base, which tends to create more problems than it solves. On the other hand, I think it is a good refactoring step if your plan is to eventually move all the composition logic at the entry point of the application.

Coming from .NET, I tend to do the wiring as close as possible to the entry point as well, but I still use a container because it makes object lifecycle management much easier, and with convention over configuration it is trivial to associate interfaces to implementations: this not only reduces wiring up code for complex applications to a few lines, it also makes the rest of the application container-agnostic, which is quite cool.

[bborud]

> t also makes the rest of the application container- > agnostic, which is quite cool.

Not least because containers have a tendency to fall out of fashion. For instance if you suggest using Spring for a large project now, people will queue up to punch you like a meat pinata.