Part 2. DI catalog

Part 1 provided an overview of DI, discussing the purpose and benefits of DI and explaining how DI CONTAINERS fit into the overall picture. Even though chapter 2 contained an extensive example, I’m sure the first chapters still left you with some unresolved questions. In part 2, we dig a little deeper to answer some of those questions.

As the title of part 2 implies, this is a catalog of patterns, anti-patterns, and refactorings. Some people dislike design patterns because they find them dry or too abstract. Personally, I love patterns because they provide us with a high-level language that makes us more efficient and concise when we discuss software design. It’s my intent to use this catalog to provide a pattern language for DI. Although a pattern description must contain some generalizations, I’ve attempted to make each pattern concrete, using examples.

You can read all three chapters in sequence, but each item in the catalog is also written so that you can read it by itself.

Chapter 4 contains a mini-catalog of DI design patterns. In a sense, these patterns constitute prescriptive guidance on how to implement DI, but you should be aware that I don’t consider them to be of equal importance. CONSTRUCTOR INJECTION is by far the most important design pattern, whereas all the other patterns should be treated as fringe cases that can be applied in specialized circumstances. The AMBIENT CONTEXT pattern, in particular, should be so rarely employed that I seriously considered not including it in the book (I only left it in because those who read the book before publication asked me to keep it).

Whereas chapter 4 gives you a set of generalized solutions, chapter 5 contains a catalog of situations to avoid. These anti-patterns (or code smells) describe common, but incorrect ways to address typical DI challenges. In each case, the anti-pattern describes how to identify occurrences and how to resolve the issue. It’s important to know and understand these anti-patterns to avoid the traps that they represent, and, just as chapter 4 presents one dominatingly important pattern, the most important anti-pattern is SERVICE LOCATOR, the antithesis of DI.

As you apply DI to real-life programming tasks, you will run into some challenges. I think we’ve all had moments of doubt where we feel that we understand a tool or technique, and yet we think, “In theory, this may work, but my case is special...” Whenever I find myself thinking like this, it’s clear to me that I have more to learn.

During my career, I’ve seen a particular set of problems appear again and again. Each of these problems has a general solution you can apply to move your code towards one of the DI patterns from chapter 4. In the spirit of refactoring to patterns I chose to call this chapter DI refactorings, because it contains a catalog of issues and corresponding solutions.

Part 2 presents a complete catalog of patterns, anti-patterns, and refactorings. I expect this to be the most useful part of the book, because it’s the most enduring. Hopefully, you’ll return to these chapters months and even years after you first read them.