How does dependency injection differ from just not using global variables?

Question

I have been reading alot about dependency injection thinking that it may be some really advanced way to program, but I can't see the difference between just avoiding global state, as when there is no global state then you are forced to pass in all dependencies to objects.

Can someone please explain to me as I think I may be missing the point about what dependency injection is?

Answer 1

Dependency injection is about decoupling code.

When you avoid the use of globals by passing arguments you are decoupling code. You are removing the dependency the code has on the globals.

You can generalize this decoupling to more than just the avoidance of globals. Take the following code:

def foo(arg):
   return ClassBar(arg).attr

foo(1)

The function foo is dependent on or tightly coupled to ClassBar. The reason this is not good is you will be forced to update foo when:

• the arguments to constructing ClassBar change
• you want to change ClassBar to something else
• another piece of code wants to access attr from a different object

If the code was rewritten:

def foo(instanceBar):
   return instanceBar.attr

foo(ClassBar(1))

You've pushed the coupling up to the caller. This removed the dependency from the definition of foo. This frees you from having to update foo in the cases outlined above. The more of your code that is decoupled, the fewer code changes you'll need to make.

Answer 2

What I understand about dependency injection is that you leave out the details of creating an object and only declare that such an object is needed. A framework for example will set this object later on before it's needed.

So the value here is the separation of concerns. This is useful for testing when you will inject a mockup of the real object.

Answer 3

Dependency injection is a way for implementing the inversion of control pattern for avoiding global state for dependency resolution. You can use the inversion of control pattern with or without dependency-injection. Yes not using global variables is an important part of the equation weather you use dependency-injection or not.

Dependency injection is really nothing more than if you were to write a program in a bottom up style where the most top level portion of the application resolved dependencies for all subsystems. Say I had a program with a dependency injection configuration like:

 <bean id="world" class="com.game.World" start-method="play">
    <property name="player1" ref="player1"/>
    <property name="player2" ref="player2"/>
 </bean>

 <bean id="player1" class="com.game.LocalPlayer"/>
 <bean id="player2" class="com.game.NetworkPlayer/>

That would really be no different than if you created the objects by hand:

 public static void main() {
    World world = new World();
    world.player1 = new LocalPlayer();
    world.player2 = new NetworkPlayer();

    world.play();
 }

Using dependency injection simply means writing code like the above is handled for you. In this simple example you can't make much of a case for using it over just using code, but in larger programs it does save you a lot of time. It also prevents you or team members from taking shortcuts because it's not as wide open as when you write code.

Dependency-injection frameworks change your program from imperative style code to a declarative-style language for dependencies. So you're writing a program through this declarative language and you can augment that with lots of other features.

Features like having the framework resolve order of construction and cycle dependencies for you. Declaring external configuration and injection of values into your declared objects (i.e. property files, XML configuration, etc) which is really nice. All of these together makes dependency injection frameworks quite compelling to use over doing all of this on your own.

Answer 4

Another thing is that dependency injection generally creates singleton objects. In situations like services and DAOs, you would never want to have more than one object. Its also nice to have it instantiated already(generally on app startup, in spring), so you can use whenever needs arise.

Answer 5

Assuming you are a good coder, you want to be able to test and replace your parts system easily. The best way to do this is with a modular design. That is to say you want to break down your problem into smaller problems that you can solve and keep bug free.

By using dependency injection, you are able to come up with these smaller components, test them and link them together in a standard way. This in tern results in slicker, decoupled design. In turn, your project doesn't grind begin to slow as you are never working in high complexity code (at least in theory) this productivity remains high.

If you are a skilled developer you can make use of the singleton pattern (and others) to get most of the same benefits. However, your entire team needs to have this same skill or once again you get coupled design and low throughput.

Answer 6

Using dependency injection looks to be like using Windows registry. You load up the registry with things you want and then pull them out and use them in some module.

However, it breaks Object oriented code.

Say you have 20 items in your Dependency registry. A database, a logger, an exception handler and so on.

Now in a given module you have NO IDEA which of these dependency services your module uses. Your context is further lost because you don't know what will be in the dependency registry at the time you run the code!

I cannot see any benefit here. It simply makes debugging impossible.