55

I've been reading up more on the Inversion of Control principle and Dependency Injection as an implementation of it and am pretty sure I understand it.

It seems to be basically saying 'don't declare your class members' instantiations within the class'. Rather that the instantiations should be passed in and assigned through the constructor; 'injected' into the class from an outside source.

If it's this simple, which it seems to be, why do we need frameworks like spring or guice that implement this with annotations? Am I missing something fundamental here? I'm really struggling to understand what the use of Dependency Injection frameworks are.

Edit: About the possible duplicate, I believe my question is more unique as it is asking about DI frameworks in general, not just Spring. Spring is not just a DI framework, so there are many reasons that someone would want to use Spring that aren't related to DI.

timsworth
  • 661

4 Answers4

37

We don't need the frameworks. It is entirely possible to implement dependency injection manually, even for a relatively large project.

On the other hand, using a framework makes it easier, particularly one based on annotations or automatic detection of dependencies, as it makes the process simpler: if I decide that I need a new dependency in a class, all I have to do is add it to the constructor (or declare a setter) and the object is injected - I don't need to change any instantiation code.

Also, frameworks often contain other useful functionality. Spring, for example, contains a useful framework for aspect oriented programing, including declarative transaction demarcation (which is extremely handy) and a variety of adapter implementations that make many 3rd party libraries easier to integrate.

Jules
  • 17,880
  • 2
  • 38
  • 65
18

  1. Why do we need DI (Dependency Injection) at all?

    The DI mechanism separates object production from object consumption. The dependecies an object needs are delivered transparently from the outside. The advantage of the mechanism is clear: You could anytime swap out dependencies, e.g. usìng a Null Object for testing purposes.

  2. How is it done?

    There are several ways to achieve the goal:

    • Injecting dependencies via constructor injection
    • Injection via getter/setter
    • Interface Injection

  3. Do we need DI frameworks?

    No. Not at all. You could simply pass all instances to other objects manually. If you have a small application, there is no need for a spring container.

    But on the other hand, frameworks give you a helping hand, managing objects:

    • They help you wiring up complex object relationships. You have to write no boilerplate code, to generate instances and pass them to the appropriate objects

    • They help you control when an object is created: you could create instances during application bootstrapping, but in some cases a lazy creation - only when needed - is better

    • They help you control how many instances are created: one per application lifetime or one per request (in case you are doing web-programming)

If you project has an appropriate size - if you feel the need to write less boilerplate code - it totally makes sense using a (DI-) framework. There are more pros than cons.

Tulains Córdova
  • 39,570
  • 13
  • 100
  • 156
Thomas Junk
  • 9,623
  • 2
  • 26
  • 46
5

With spring, it is mostly a matter of convenience.

If you have class TopLevel which is constructs class MiddleLevel which constructs class LowLevel, and you realize you need a new constructor parameter on LowLevel, you have to also add it to TopLevel, and to MiddleLevel, simply so that when it is time for MiddleLevel to construct a LowLevel the value will be available so that it can be passed to its constructor. With spring, you just add an annotation.

Also, with spring, it is possible to define the dependencies in an external configuration file instead of xml, and this supposedly gives you the ability to generate a new system with an entirely different wiring "without changing any code". (IMHO this is completely misdirected, because altering xml is not that much different from altering code, and actually, code usually has far better error checking and type checking than xml does.)

Another thing is that many people are afraid of constructors; they don't understand them, they don't like them, they'd rather not use them.

Mike Nakis
  • 32,803
2

A few years ago I wrote a program to monitor web pages, web portlets, even certain database tables, at a company I used to work for. I wanted it to be flexible enough that the user could specify which monitors would run and with which parameters (urls, logins, success criteria, etc.). So I wrote it to read from an XML file and use Java reflection to instantiate the specified classes and use setter methods to set the specified parameters.

Later I found that out Spring will do the same thing for you, and a whole lot more.

So in my case I found that

  1. Using a dependency injection framework helps make the program flexible and makes it easier to specify how it will operate (within well defined parameters of course).

  2. Using a third party DI framework keeps you from having to reinvent the wheel.

Paul J Abernathy
  • 155