dependency injection (DI)
Dependency injection (DI) is a term associated with object-oriented programming. It expresses that modules(objects, classes) get their dependencies - information or a certain behavior by calling methods - assigned by another, external instance, which is then also called injection. This injection is performed by a DI framework - such as the Spring or Unity frameworks. Closely related to the concept of Dependency Injection is the principle of Inversion of Control - the reversal of the flow of control. Three different types of dependency injection can be distinguished: setter injection, constructor injection and interface injection.
This also makes clear the levels at which injection takes place. The goal of using DI is to minimize dependencies between modules. Dependency Injection is also a concept, which can be used as a component of a software architecture. The term Dependency Injection was coined and introduced by Martin Fowler. A detailed description by Martin Fowler on this topic is available at the link below.
Inversion of Control
Since the beginning of object orientation the principle of Inversion of Control( IoC) is an aspect discussed in this context. But only in the course of the further development of object-oriented programming languages and concepts as for example in the environment of C++, Java, Python and others this topic became more popular again; although the principle is by no means a new invention. Now Inversion of Control is to be understood as a general characteristic of frameworks, which one calls in the general language use also the so-called Hollywood principle "Don't call us, we'll call you!". This means that the responsibility for program execution lies on the side of the framework - which is also referred to as reverse control flow. Thus the responsibility lies expressly not with the components, which were developed on basis of this framework. For this purpose, the corresponding modules must implement so-called callback methods(callbacks). Here the run time environment for the framework is made available by a container. The callbacks give the framework during the runtime the possibility of the delivery - the injection - of information to these modules or also by injection a certain behavior of modules by the call of their methods to realize. Thus also the life cycle of a complete module can be influenced from the outside by the callbacks.
Dependency Injection (DI) is a special form of the Inversion of Control principle, which was defined and introduced by Martin Fowler. The background was the predominant use of the Inversion of Control principle for the injection of references to required resources by lightweight frameworks like Spring and containers like PriceContainer or Excalibur. DI allows services of so-called service factories to be hidden from the outside world. In object orientation, factories are objects that can in turn create other objects. Thus, the use of DI should not create dependencies between modules and classes. The responsibility for the interaction of modules lies in each case with the framework, which needs for this further information concerning the configurations of these modules. These are integrated either directly into the code or are available however separately in a configuration file - frequently a XML file. The delivery of used objects to objects to be used will thus always take place on basis of these configuration information. The choice of configuration depends on the individual case.
The different forms of Dependency Injection
There are three fundamentally different forms of Dependency Injection when passing modules:
Setter Injection The DI framework uses the setter method to ensure that a required module is injected.
Constructor Injection In constructor injection, the required modules are passed as arguments to the constructor of a class.
Interface Injection Here, the injection is done via explicitly implemented interfaces on the side of the used module as well as on the side of the using module. This possibility of the injection is avoided in practice however, since by the implementation of the interfaces again dependencies result.
It is advantageous to use DI when merging an application from different modules. Different kinds of the configuration can be supported by the procedure. By the assignment of modules to a configuration arbitrary forms of the configuration can be developed by the Framework for example special server configurations or test configurations. Thereby the emphasis of Dependency Injection lies on the decoupling of modules, which have otherwise no contact. Dependency Injection should not be seen as a replacement for factories. With the configuration of the modules over separate files there is however also a large disadvantage for the developer - the expirations of an application are no longer comprehensible without exact knowledge of the configuration file.
For different programming languages as well as platforms there are the most different frameworks, which support Dependency Injection:
- For Java: Spring, EJB 3.0, Seam, Guice.
- For . NET: Unity, Ninject, ObjectBuilder, LightCore, PicoContainer, Structuremap.
- For Python: PyContainer.
- For Ruby: Needle,Copland.
- For C++: DSM.
- For PHP5: Garden, Symfony Components, Stubbles IoC.
An alternative way to Dependency Injection are so called Service Locator - this is a parent directory of services. The service locator knows a corresponding realization for all services that an application needs and makes them available to it on request. However, since nothing happens here without the using module explicitly requesting it, it is not possible to speak of a reversal of the control flow - the prerequisite for dependency injection.