Dependency Injection Demystified ?? Not Entirely!

I came across the sharing article by James Shore about his interpretations on the topic as captioned. Just like what it said, he unveiled the theory of Dependency Injection (or, Inverse of Control (IoC)), and shrunk it from pages of tedious articles in some web sites, into just a few paragraphs with code examples. (Click here to read his article. Really recommend you to spend less than 10 min. to read through if you have already started feeling puzzled)

Despite those thankful responses telling him how simple and clear his explanation was, I could not be persuaded that the concept is merely "just passing in an instance variable" as he suggested. It is correct, however, just cannot truly enlighten people around still confused by those bells and whistles after reading and reading. There are certainly quite a number of important concepts hidden which made this DI sounds innovative. Therefore I wrote up a comment in his blog, and would like to share my own understandings here.

Below are just the copy-and-paste of my comment in his blog.

***

I do agree that reading more and more of those IoC articles may just complicate our mind set on simple concepts, and turn out getting less than 5% from what it said after read. The explanation of your article is simple and clear, but not inspiring enough. People would always ask "What can this IoC work with me?"  
 
Please let me make a few more points here to make the idea a little bit more complete (not more complicated).  
 

1

An object comprises of fields ( States), and methods ( Behaviours). To change the behaviour of a program, traditionally we always modify the codes inside the method of that object, and then recompile.

2

Now, can we merely do configurations instead of code changes? People think of setting up system/global parameters. But these parameters can grow and are hard to get managed as behaviours become manifold and scrupulous.

3

Why can't we maintain behaviours directly out of the box? In the object world, we define a new object with a common method interface exposed ( Encapsulation), and put the varying behaviour inside the method ( Polymorphism). Objects become the units/components storing the behaviour definitions.

4

So forth, we extract the varying behaviours out to be new objects, and let the program ( caller) we originally worked on call these new objects ( component). Now we may control the behaviour of the program by just swapping the components ( Inverse of Control).

5

Can we swap the components externally? In that case, the configuration mechanism should enable us to set the components into the caller from outside ( Injection). Components are not anymore instantiated inside the caller (no more  new inside program).

6

What if we want to fine tune the behaviour of individual components? We may just do the same steps to the components as we did to the original program! The components may now become the caller to another layer of new components ( Dependency Injection Chain).

7

Now we can configure the behaviour of the entire program by swapping individual components in any layer throughout the system. We no longer change codes often as before. Moreover, it gives us an overall picture of the program behaviour merely from the configuration. Instead of being regarded as programmers, we have evolved to be assemblers.