Does anyone have a good analogy for dependency injection? [closed]

Answer 1

The essence of Inversion of Control (of which Dependency Injection is an implementation) is the separation of the use of an object from the management thereof.

The analogy/example I use is an engine. An engine requires fuel to run, i.e. it is depdendent on fuel. However, the engine cannot be responsible for the fuel it needs. It just 'asks' for fuel, and it is provided (typically by a fuel pump in a car).

The analogy starts breaking down when you look too deep, in that an engine doesn't ask for fuel, it is given it by some kind of management element, like an ECU. One might be able to compare the ECU to a container but I'm not certain how valid this is.

Answer 2

I think a great analogy is a six-year-old with a lego set.

You want your objects to be like the lego bricks. Each one is independent of all the others, and yet offers a clear interface for connecting them to the others. When connecting them together, it doesn't really matter exactly which two bricks you hook together so long as they have a matching interface.

Your dependency injection framework is like the six-year-old. He follows the instructions (i.e., your config file, annotations, etc.) to connect specific bricks together in certain ways to make a particular model.

Of course, since the bricks' interfaces are pretty generalized, they can go together in lots of different ways, so it's easy to come up with new sets of instructions which the six-year-old can use to make a completely different model out of the same bricks.

Answer 3

From Head First Design Patterns:

Remember, code should be closed (to change) like the lotus flower in the evening, yet open (to extension) like the lotus flower in the morning

A DI-enabled object can be configured by injecting behaviors defined in other classes. The original object structure doesn't have change in order to create many variations. The injection can be made explicit by having a class request other worker-classes in its constructor, or it can be less obvious when using monkeypatching in dynamic languages like Python.

Using an analogy of a Person class, you can take a basic human framework, pass it a set of organs, and watch it evolve. The Person doesn't directly know how the organs work, but their behaviors confirm to an expected interface and influence the owner's physical and mental manifestation.

Answer 4

Analogy? I'll give it a whack... Your CD Player stereo is useless without a CD with music on it... (It's dependent on the CD). If they built CD Players with the CD already in it, it would get boring very quickly...

So they build them so you can "inject" the CD, (on which it is dependent) into the player. That way you can inject a different one each time, and get "different" behavior (music) dependent on which one you inject.

The only requirement is that the CD must be compatible with the interface defined by the player. (You can't play a blue-ray disk in a 1992 CD player.)

Answer 5

Your project manager asks you to write an app.

You could just write some code based on your career experience so far, but it's unlikely to be what your PM wants.

Better would be if your PM dependency injected you with say a spec for the app. Now your code is going to be related to the spec he gives you.

Better if you were told where the source repository was.

Better if you were told what the tech platform was.

Better if you were told when this needed to be done by.

Etc..

Answer 6

Think of it as a realisation of the "Inversion of Control" pattern. I guess, your problem is, you are so used to it, you don't realize it's that simple.

Let's start at the beginning.

In the early days programs followed a given path through the code. The order of the called functions was given by the programmer.

In interactive programs, e.g. mostly ANY program, you can not say, which function is called at what time. Just look at a GUI or website. You can not say, at what time what button or link is clicked. So the "control" of what's happening is no longer at the program, it's at an outer source. The "control" has been inverted. The function is no longer "acting" it is instead "listening". Think of the hollywood principle: "Don't call us, we call you". A listener is a good example for a realisation of this pattern.

IoC is realized by functions or "methods" in the "object oriented world" of today.

"Dependency Injection" now means the same, but not for "methods", which do something, but for "objects", which hold data.

The data is no longer part of the object holding it. It is "injected" into the object at runtime. To stay in hollywood, think of a film star, playing golf to talk about the business, but to keep in shape, she hungers herself down, minimizing her muscle weight and therefore she is only able to carry one club at a time.

So, on the golf course her game would heavily depend on the one club, she is carrying.

Lucky for her, there are caddies, carrying a whole lot of clubs at one time, and also having the knowledge what club to use at what time. Now she is independent of her limited possibility to carry golf clubs. "Don't think about a concrete club to wear, we know them all and give you the right one at the right time".

The film star is the object and the golf clubs are the members of the object. That's dependency injection.