Is is an anti-pattern to inject DI container to (almost) each class?

Question

Lately I find myself not caring too much defining dependencies for a class and passing them in the constructor, but I just always pass the DI container and keep it in a priv

Answer 1

This is an anti-pattern and I dare to bet that you are not writing tests yet for your code which is really bad.

When you start writing tests you will find that you are writing un-testable code, and you are:

• Using the Service Locator anti-pattern

• You are violating the Law of Demeter

• You are not following the Single Responsibility Principle

• You are hiding your object real dependencies (Not using the Dependency-Injection pattern)

• You do not have a real separation between the two big piles of object in any application:

  • Business objects: Responsibility is business logic, domain abstractions
  • Wiring and building objects: Responsibility is to build object graphs

The day you want to write unit-tests for your components you will regret this decision and you will have either refactor your code or write integration tests instead of simple unit-tests (creating a test container and inject mocks to this container).

My advise is read this guide to write testable code: (this is the guide used by the guys working hard in Google)

http://misko.hevery.com/code-reviewers-guide/

if you prefer, start with these videos from Misko Hevery about the psychology of testing and clean code talks:

http://www.youtube.com/watch?v=wEhu57pih5w&feature=player_embedded

http://www.youtube.com/watch?v=RlfLCWKxHJ0&feature=player_embedded

http://www.youtube.com/watch?v=-FRm3VPhseI&feature=player_embedded

Answer 2

Absolutely wrong. Don't put the DI container in the objects; they need not know or care that they're being injected. This doesn't square with "don't call us; we'll call you."

It's the other way 'round: the overall app knows about the DI engine, but then it gets the beans it needs from it.

I suppose you might argue that annotations change the relationship some, because now the beans do know something about the fact that they're wired together. But when configuration was externalized into XML, it was true that beans were ignorant of DI.