Dependency injection

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
m (Reverted edits by Ebybymic (Talk); changed back to last version by Joey Scarr)
 
Line 3: Line 3:
 
It can also be viewed as an example of the [[Dependency inversion principle]], because it removes dependencies from low-level concepts in favour of the higher-level abstractions.
 
It can also be viewed as an example of the [[Dependency inversion principle]], because it removes dependencies from low-level concepts in favour of the higher-level abstractions.
  
>== Participants ==
+
== Participants ==
 
This design pattern can arise in a few different forms, but there are generally three participants.
 
This design pattern can arise in a few different forms, but there are generally three participants.
  
Line 11: Line 11:
  
 
The injector (also known as a provider or container) handles all issues associated with composing these objects and managing them throughout their life cycle.  This includes when and how they are instantiated and disposed of.  The injector can be implemented as a abstract factory or service locator.
 
The injector (also known as a provider or container) handles all issues associated with composing these objects and managing them throughout their life cycle.  This includes when and how they are instantiated and disposed of.  The injector can be implemented as a abstract factory or service locator.
 
----
 
<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
 
----
 
=[http://asamusimi.co.cc Under Construction! Please Visit Reserve Page. Page Will Be Available Shortly]=
 
----
 
=[http://asamusimi.co.cc CLICK HERE]=
 
----
 
</div>
 
  
 
== Three examples of managing dependencies ==
 
== Three examples of managing dependencies ==

Latest revision as of 03:23, 25 November 2010

In the Dependency Injection pattern, an object's dependencies are provided externally. This separates behaviour from dependency resolution. It is the general concept behind the Factory patterns, which aim to reduce coupling and unwanted dependencies.

It can also be viewed as an example of the Dependency inversion principle, because it removes dependencies from low-level concepts in favour of the higher-level abstractions.

Contents

Participants

This design pattern can arise in a few different forms, but there are generally three participants.

  • Dependent: An object that is expected to perform some task
  • Dependencies: The object(s) that the dependent relies on to perform some task
  • Injector: Composes the dependent with its dependencies so it is ready to use

The injector (also known as a provider or container) handles all issues associated with composing these objects and managing them throughout their life cycle. This includes when and how they are instantiated and disposed of. The injector can be implemented as a abstract factory or service locator.

Three examples of managing dependencies

A dependency hard coded into an object:

class SimpleCar implements Car {
   private Engine engine = new SimpleEngine(); // Note the dependency on the SimpleEngine implementation

   public accelerate() {
       engine.setFuelValveIntake(gasPedalPressure);
   }
}
   

Dependency injection through the constructor:

class SimpleCar implements Car {
   private Engine engine;
   public SimpleCar(Engine engineImpl) {
       engine = engineImpl;
   }
   public void accelerate() {
       engine.setFuelValveIntake(gasPedalPressure);
   }
}

Martin Fowler described three types of dependency injection: interface, setter and constructor injection. Each method provides a slightly different way of "injecting" the dependency into a class without using hard-coded references.

There are also frameworks in most major languages for dependency injection. These frameworks let dependencies be defined with additional language syntax so that the framework can manage the dependencies - for example, an XML configuration file may be used to define what implementations should be used for each abstraction.


See also

References

Personal tools