Part 1. Putting Dependency Injection on the map

Dependency Injection (DI) is one of the most misunderstood concepts of object-oriented programming. The confusion is abundant and spans terminology, purpose, and mechanics. Should it be called Dependency Injection, Inversion of Control, or even Third-Party Connect? Is the purpose of DI only to support unit testing or is there a broader purpose? Is DI the same as Service Location? Is a DI CONTAINER required?

There are plenty of blog posts, magazine articles, conference presentations, and so on that discuss DI, but, unfortunately, many of them use conflicting terminology or give bad advice. This is true across the board, and even big and influential actors like Microsoft add to the confusion.

It doesn’t have to be this way. In this book I present and use a consistent terminology that I hope others will adopt. For the most part, I’ve adopted and clarified existing terminology defined by others, but occasionally I add a bit of terminology where none existed previously. This has helped me tremendously in evolving a specification of the scope or boundaries of DI.

One of the underlying reasons behind all the inconsistency and bad advice is that the boundaries of DI are quite blurry. Where does DI end and other object-oriented concepts begin? I think that it’s impossible to draw a distinct line between DI and other aspects of writing good object-oriented code. To talk about DI we have to draw in other concepts such as SOLID and Clean Code. I don’t feel that I can credibly write about DI without also touching on some of these other topics.

The first part of the book helps you understand the place of DI in relation to other facets of software engineering—putting it on the map, so to speak.

The first chapter gives you a quick tour of DI, covering its purpose, principles, and benefits, as well as providing an outline of the scope for the rest of the book. If you want to learn what DI is, and why you should be interested in it, this is the place to start. The chapter assumes you have no prior knowledge of DI, but even if you already know about it you may still want to read it—it may turn out to be something other than what you expected.

Chapter 1 is focused on the big picture and doesn’t go into a lot of details. Chapter 2, on the other hand, is completely reserved for a big example. This example is intended to give you a much more concrete feel for DI. It’s divided into two parts and almost shaped like a narrative. To contrast DI with a more “traditional” style of programming, the chapter first showcases a typical, tightly coupled implementation of a sample application, and then subsequently re-implements it with DI.

The third and final chapter of part 1 introduces the concept of a DI CONTAINER and explains how it fits into the overall picture of DI. I discuss DI in general terms and, although I provide code examples that demonstrate how a typical DI CONTAINER works, the purpose of the chapter isn’t to explain specific API details. The main point of chapter 3 is to show that a DI CONTAINER is a (very helpful) optional tool. It’s entirely possible to utilize DI without using a DI CONTAINER, so parts 2 and 3 more or less ignore DI CONTAINERS and instead discuss DI in a container-agnostic way. Then, in part 4, we return to DI CONTAINERS to dissect six specific containers.

Part 1 establishes the context for the rest of the book. It’s aimed at readers who don’t have any prior knowledge of DI, but experienced DI practitioners may also benefit from skimming the chapters to get a feeling for the terminology used throughout the book. By the end of part 1, you should have a firm grasp of the vocabulary and overall concepts, even if some of the concrete details are still a little fuzzy. That’s okay—the book becomes more concrete as you read on, so parts 2, 3, and 4 should answer the questions you’re likely to have after reading part 1.