What is the real difference between "Bastard Injection" and "Poor Man's Injection"

From the Dependency Injection in .NET book I know that the object graph should be created at the Composition Root of the application which makes a lot of sense to me when you are using an IoC Container.

In all the applications I've seen when an attempt to use DI is being made, there are always two constructors:

• the one with the dependencies as parameters and
• the "default" one with no parameters which in turn calls the other one "newing" up all the dependencies

In the aforementioned book, however, this is called the "Bastard Injection anti-pattern" and that is what I used to know as "Poor Man's Injection".

Now considering all this, I would say then that "Poor Man's Injection" would be just not using an IoC Container and instead coding all the object graph by hand on the said Composition Root.

So my questions are:

1. Am I understanding these concepts correctly or am I completely off track?
2. If you still need to register all the dependencies in the IoC container vs. coding them by hand in the exact same Composition Root, what's the real benefit of using an IoC container?
3. If I have misunderstood what "Poor Man's Injection" really is, could someone please clarify it?

When it comes to DI, there's a lot of conflicting use of terminology out there. The term Poor Man's DI is no exception. To some people, it means one thing and to others it means something different.

One of the things I wanted to do with the book was to supply a consistent pattern language for DI. When it came to all of those terms with conflicting use, I had two options: Come up with a completely new term, or pick the most prevalent use (according to my subjective judgment).

In general, I've preferred to re-use existing terminology instead of making up a completely new (and thus alien) pattern language. That means that in certain cases (such as Poor Man's DI), you may have a different notion of what the name is than the definition given in the book. That often happens with patterns books.

At least I find it reassuring that the book seems to have done its job of explaining exactly both Poor Man's DI and Bastard Injection, because the interpretation given in the O.P. is spot on.

Regarding the real benefit of a DI Container I will refer you to this answer: https://stackoverflow.com/questions/5667801/arguments-against-inversion-of-control-containers/5668093#5668093

---

P.S. 2018-04-13: I'd like to point out that I've years ago come to acknowledge that the term Poor Man's DI does a poor (sic!) job of communicating the essence of the principle, so for years, now, I've instead called it Pure DI.

---

P.P.S. 2020-07-17: We removed the term Bastard Injection from the second edition. In the second edition we simply use the more general term Control Freak to specify that your code "depend[s] on a Volatile Dependency in any place other than a Composition Root."

Some notes to the part 2) of the question.

> If you still need to register all the dependencies in the IoC container vs. coding them by hand in the exact same Composition Root, what's the real benefit of using an IoC container?

• If you have a tree of dependencies (clasess which depend on dependencies which depend on other dependencies and so on): you can't do all the "news" in a composition root, because you new up the instances on each "bastard injection" constructor of each class, so there are many "composition roots" spreaded along your code base

• Wheter you have a tree of dependencies, or not, using an IoC container will spare typing some code. Imagine you have 20 different classes that depend on the same IDependency. If you use a container you can provide a configuration to let it know which instance to use for IDependency. You'll make this in a single place, and the container will take care to provide the instance in all dependent classes

• The container can also control the object lifetime, which offers another advantage.

All of this, apart of the other obvious advantages provided by DI (testability, maintainability, code decouplig, extensibility...)

We've found, when refactoring legacy applications and decoupling dependencies, that things tend to be easier when done with a two step process. The process includes both "poor man" and formal IoC container systems.

First: set up interfaces and establish "poor mans ioc" to implement them.

• This decouples dependencies without the added overhead (and learning curve) of a formal IoC set up.
• This also reduces interference with the existing legacy code. Nothing like introducing yet another set of issues to debug.
• Development team members are never at the same level of expertise or understanding. So it saves a lot of implementation time.
• This also allows a footing for test cases.
• This also establishes standards for a formal IoC container system later.
• This can be implemented in steps over time by many people.

Secondly: Each IoC system has pros & cons.

• Now that an application standard is established, an educated decision can be made in choosing an IoC container system.
• Implementing the IoC system becomes a task of swapping the "poor mans" code with the new IoC system.
• This can be implemented in steps over time and in parallel with "poor man". It is better to head this with one person.