What's a good metaphor for Dependency Injection?

Question

A metaphor that stuck with me when programming non-DI systems is "a person playing with his/her toys". A person being an object and the person's toys being anything that object creates, stores, initializes, and manipulates. The toys can dispatch events when they reach a certain state, but they know nothing about the person using them; they're just little black boxes with control switches that make up their interfaces. The person can listen for events from the toys and respond by manipulating their interfaces. The person can do whatever he/she wants with his/her toys, but he/she probably shouldn't go meddling with their innards because they might break.

The havoc that DI wreaks upon my metaphor is that it turns the toys into conscious beings that know their owner, the person using them. The toys can manipulate this person, but the person knows nothing of how they work and doesn't even care. The person just owns the toys and expects the toys to manipulate him/her to the toys' own satisfaction.

WTF?? That sounds horrible!!
What is a good mental metaphor they've been using to think of how DI systems work?

Answer 1

The toys aren't conscious. They just let the person tie bits of string to hooks, and when certain things happen, the hooks turn and the string gets pulled on, so the person knows something happened.

Answer 2

From my perspective the difference between DI and non-DI with respect to your metaphor is with non-DI systems, each person makes their own toys -- they have to know how to make them and they can only use the toys they make. With DI, the person uses the toys they are given. They don't know how to make them, but they can play with any toys they are given as long as they know how the toy behaves.

Answer 3

Think a gentleman and his butler. The butler (the DI framework) provides to the gentleman any services (external dependencies) he needs upon demand (and some, like the morning coffee, upon "initialization" :-)); the gentleman (your class) just consumes the services and does not care where they come from, as long as they meet his requirements (implement certain interface).

Or if you want to make it closer to your metaphor, your class is the kid, the DI framework is the mom, and the toys are the other components. The kid doesn't care where the toys come from, as long as she can play the way she wants with them.

Answer 4

It's all about Samurais and weapons. Try checking out ninject: http://ninject.org/. Go to the "Visit the Dojo" character for an interesting metaphor. Not sure if this is what you meant but it's creative nonetheless.

Answer 5

Legos.

Think of a Lego block as a software component that exposes one or more interfaces (the little bumps on top) and has one or more setters or constructor arguments (the holes on the bottom).

When you buy a box of Legos, the blocks don't come preassembled (hard-wired). They are independent components. You then assemble them (wire them) by connecting interfaces (bumps) to setters/constructors (holes). Each block knows nothing about the other blocks directly. Something other than the block is required to assemble them - that is you (or main() or a Spring config file, etc.).

I know... this breaks down a bit because Legos largely have a uniform interface - but it works for me :-)

Answer 6

I use computer system. You have a system block, and you (a DI) connect to it a monitor, a keyboard and a mouse. The system block only knows that a monitor is a DVI device, but cares not which monitor precisely it is. It knows how to use USB-mouse, but does not know or care weather it is an optical or a ball-rolling mouse.

You - the DI framework.
System block - is the system being served.
Monitor/mouse/keyboard - services provided by DI (you) to the system block.

Answer 7

One DI metaphor that I was told was to relate it to was that of a CD player. The player doesn't care what CD you put in; however, each CD you inject into the player provides different functionality based on what the player requires from it.