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

Question

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 o

Answer 1

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...)

Answer 2

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: Arguments against Inversion of Control containers

---

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."

Answer 3

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.