Dependency injection (DI) is a design pattern in object-oriented computer programming whose purpose is to reduce the coupling between software components. It is similar to the factory method pattern. Frequently an object uses (depends on) work produced by another part of the system. With DI, the object does not need to know in advance about how the other part of the system works. Instead, the programmer provides (injects) the relevant system component in advance along with a contract that it will behave in a certain way.

Motivation

Developers of software strive to reduce dependencies between components for various reasons. This leads to a new problem, though: How can a component know all the other components it needs to fulfill its purpose?

The traditional approach was to hard-code the dependency. For instance, as soon as the database driver was necessary, the component would execute a piece of code that would load a specific driver, configure it, and call the necessary methods to interact with the database. If a second database must be supported, this piece of code would have to be modified or, even worse, copied and modified (violating the DRY principle).

The dependency injection offers a solution. Instead of hard-coding the dependencies, a component just lists the necessary services and a DI framework supplies these. At runtime, an independent component will load and configure the database driver and offer a standard interface to interact with the database. Again, the details have been moved from the original component to a set of new, small, database-specific components, reducing the complexity of them all. In DI terms, these new components are called "service components", as they render a service (database access) for one or more other components.

Dependency injection is a specific form of inversion of control, where the concern being inverted is the process of obtaining the needed dependency. The term was first coined by Martin Fowler to describe the mechanism more clearly.

Basics

Without dependency injection, a consumer component that needs a particular service in order to accomplish a task will depend not only on the interface of the service, but on the details of a particular implementation of it as well. The user component has to handle both its use and the life cycle of that service - creating an instance, opening and closing streams, disposing of unneeded objects, etc.

Using dependency injection, however, the life-cycle of a service is handled by a dependency provider rather than the consumer. The dependency provider is an independent, external component that links the consuming component and the providing component. The consumer would thus only need a reference to an implementation of the service that it needed in order to accomplish the necessary task.

Such a pattern involves at least three elements:

a dependent consumer,

the definition of its service dependencies, and

an injector (sometimes referred to as a provider or container).

The dependent is a consumer component that needs to accomplish a task in a computer program. In order to do so, it needs the help of various services (the dependencies) that execute certain sub-tasks. The provider is the component that is able to compose the dependent and its dependencies so that they are ready to be used, while also managing these objects' life cycles. The provider may be implemented, for example, as a service locator, an abstract factory, a factory method, or a more complex abstraction such as a framework.

The following is an example: A car (the consumer) depends upon an engine (the dependency) in order to move. The car's engine is made by an automaker (the dependency provider). The car does not know how to install an engine into itself, but it needs an engine in order to move. The automaker installs an engine into the car and the car utilizes the engine to move.

When the concept of dependency injection is used, it decouples high-level modules from low-level services. The result is called the dependency inversion principle.

Code illustration using Java

Using the car/engine example mentioned above, the following Java examples show how coupled (manually-injected) dependencies and framework-injected dependencies are typically staged.

public interface ICar { public float getSpeed(); public void setPedalPressure(final float PEDAL_PRESSURE); }

public interface IEngine { public float getEngineRotation(); public void setFuelConsumptionRate(final float FUEL_FLOW); }

Highly coupled dependency

The following shows a common arrangement ''with no dependency injection applied'':

public class DefaultEngineImpl implements IEngine { private float engineRotation = 0;

public float getEngineRotation() { return engineRotation; }

public void setFuelConsumptionRate(final float FUEL_FLOW) { engineRotation = …; } }

public class DefaultCarImpl implements ICar { private IEngine engine = new DefaultEngineImpl();

public float getSpeed() { return engine.getEngineRotation()*…; }

public void setPedalPressure(final float PEDAL_PRESSURE) { engine.setFuelConsumptionRate(…); } }

public class MyApplication { public static void main(String[] args) { ICar car = new DefaultCarImpl(); car.setPedalPressure(5); float speed = car.getSpeed(); System.out.println("Speed of the car is " + speed); } }

In the above example, using the ICar interface, an engine instance is created by using the IEngine interface in order to perform operations on the car. Hence, it is considered highly-coupled, because it couples a car directly with a particular engine implementation.

In cases where the DefaultEngineImpl dependency is managed outside of the scope of the car, the class of the car implementing the ICar interface must not instantiate the DefaultEngineImpl dependency. Instead, that dependency is injected externally.

Manually injected dependency

Refactoring the above example to use manual injection:

public class DefaultCarImpl implements ICar { private IEngine engine;

public DefaultCarImpl(final IEngine engineImpl) { engine = engineImpl; }

public float getSpeed() { return engine.getEngineRotation()*…; }

public void setPedalPressure(final float PEDAL_PRESSURE) { engine.setFuelConsumptionRate(…); } }

public class CarFactory { public static ICar buildCar() { return new DefaultCarImpl(new DefaultEngineImpl()); } }

public class MyApplication { public static void main(String[] args) { ICar car = CarFactory.buildCar(); car.setPedalPressure(5); float speed = car.getSpeed(); System.out.println("Speed of the car is " + speed); } }

In the example above, the CarFactory class assembles a car and an engine together by injecting a particular engine implementation into a car. This moves the dependency management from the DefaultCarImpl class into the CarFactory class. As a consequence, if the DefaultCarImpl needed to be assembled with a different IEngine implementation, the DefaultCarImpl code would not be changed.

In a more realistic software application, this may happen if a new version of a base application is constructed with a different service implementation. Using factories, only the service code and the factory code would need to be modified, but not the code of the multiple users of the service. However, this still may not be enough abstraction for some applications, since in a realistic application there would be multiple factory classes to create and update.

Framework-managed dependency injection

There are several frameworks available that automate dependency management through delegation. Typically, this is done with a container using XML or metadata definitions. Refactoring the above example to use an external XML-definition framework:

DefaultCarImpl DefaultEngineImpl

/** Implementation not shown **/

public class MyApplication { public static void main(String[] args) { Service service = (Service)DependencyManager.get("CarBuilderService"); ICar car = (ICar)service.getService(Car.class); car.setPedalPressure(5); float speed = car.getSpeed(); } }

In the above example, a dependency injection service is used to retrieve a CarBuilderService service. When a car is requested, the service returns an appropriate implementation for both the car and its engine.

As there are many ways to implement dependency injection, only a small subset of examples is shown herein. Dependencies can be registered, bound, located, externally injected, etc., by many different means. Hence, moving dependency management from one module to another can be accomplished in many ways.

Benefits and drawbacks

One benefit of using the dependency injection approach is the reduction of boilerplate code in the application objects since all work to initialize or set up dependencies is handled by a provider component.

Another benefit is that it offers configuration flexibility because alternative implementations of a given service can be used without recompiling code. This is useful in unit testing, as it is easy to inject a fake implementation of a service into the object being tested by changing the configuration file.

However, there should exist a definite reason for moving a dependency away from the object that needs it. One drawback is that excessive or inappropriate use of dependency injection can make applications more complicated, harder to understand, and more difficult to modify. Code that uses dependency injection can seem ''magical'' to some developers, since instantiation and initialization of objects is handled completely separately from the code that uses them. This separation can also result in problems that are hard to diagnose. Additionally, some dependency injection frameworks maintain verbose configuration files, requiring that a developer understand the configuration as well as the code in order to change it. For example, suppose a Web container is initialized with an association between two dependencies and that a user who wants to use one of those dependencies is unaware of the association. The user would thus not be able to detect any linkage between those dependencies and hence might cause drastic problems by using one of those dependencies. (citation needed)

Another drawback is that some IDEs might not be able to accurately analyze or refactor code when configuration is "invisible". Some IDEs mitigate this problem by providing explicit support for various frameworks. Additionally, some frameworks provide configuration using the programming language itself, allowing refactoring directly. Other frameworks, such as the Grok Web framework, introspect the code and use convention over configuration as an alternative form of deducing configuration information. For example, if a Model and View class were in the same module, then an instance of the View will be created with the appropriate Model instance passed into the constructor.

Types

Fowler identifies three ways in which an object can get a reference to an external module, according to the pattern used to provide the dependency:

''Type 1'' or ''interface injection'', in which the exported module provides an interface that its users must implement in order to get the dependencies at runtime.

''Type 2'' or ''setter injection'', in which the dependent module exposes a setter method that the framework uses to inject the dependency.

''Type 3'' or ''constructor injection'', in which the dependencies are provided through the class constructor.

It is possible for other frameworks to have other types of injection, beyond those presented above.

See also

Architecture description language

Strategy pattern

Plug-in (computing)

References

External links

A beginners guide to Dependency Injection

Dependency Injection & Testable Objects: Designing loosely coupled and testable objects - Jeremy Weiskotten; Dr. Dobb's Journal, May 2006.

Design Patterns: Dependency Injection -- MSDN Magazine, September 2005

DI cartoon

Martin Fowler's original article that introduced the term Dependency Injection

P of EAA: Plugin

The Rich Engineering Heritage Behind Dependency Injection - Andrew McVeigh - A detailed history of dependency injection.

What is Dependency Injection? - An alternative explanation - Jakob Jenkov

Writing More Testable Code with Dependency Injection -- Developer.com, October 2006

Managed Extensibility Framework Overview -- MSDN

Category:Component-based software engineering Category:Software architecture Category:Software design patterns

cs:Vkládání závislostí de:Dependency Injection es:Inyección de dependencias fr:Injection de dépendances nl:Dependency injection ja:依存性の注入 pl:Wstrzykiwanie zależności pt:Injeção de dependência ru:Внедрение зависимости

Name	The Clean
Background	group_or_band
Origin	Dunedin, New Zealand
Years active	1978–present
Label	Flying Nun Records, Merge Records
Current members	Hamish KilgourDavid KilgourRobert Scott
Past members	Peter GutteridgeDoug Hood }}

The Clean are an influential Indie rock band that formed in Dunedin, New Zealand in 1978. Led through a number of early rotating line-ups by brothers Hamish and David Kilgour, the band settled down to their well-known and current line-up with bassist Robert Scott. Early incarnations of The Clean included Peter Gutteridge on bass (who wrote "Point That Thing") and Doug Hood on vocals (who later worked with Toy Love and founded the "Looney Tours" touring company). The Clean forged a distinctive and quirky sound that relied heavily on organ melodies and simple, Ramones-style chord progressions.

History

The band's auspicious 1981 debut single "Tally Ho!" was the second release on Roger Shepherd's Flying Nun label. Featuring a chugging rhythm and instantly memorable descending farfisa line, "Tally Ho!" reached number 19 on the New Zealand Singles Charts, giving the fledgling label its first hit. A follow-up track on the band's ''Great Sounds Great'' EP titled "Beatnik" also achieved success, as did their second single, "Getting Older".

The Flying Nun label went on to become New Zealand's biggest independent record company, championing the Dunedin Sound, a loosely-connected style of music largely produced by bands from the southern city. Other artists on the label included The Chills, The Verlaines, The Bats, and Sneaky Feelings. The line-ups of these bands were often interrelated, with Peter Gutteridge being a founding member of The Chills, David Kilgour briefly in The Chills off-shoot band Time Flies, and Robert Scott being the founder of The Bats.

During much of the 1980s, The Clean disbanded, and during this time the Kilgour brothers worked together on an experimental album and EP using the deliberately punning titles "The Great Unwashed" and "Clean Out of Our Minds". Reforming in the late 1980s, the band explored a slightly poppier vein of music while still retaining their experimental edge.

Although they released several chart-topping singles in their native country, The Clean are a little-known cult band outside of New Zealand, although their influence is surprisingly far-reaching. They became a staple of college radio in the 1980s, Stephen Malkmus of Pavement cites them as a major influence, and the band's droney 80s output is a direct forerunner of bands such as Yo La Tengo and Camper Van Beethoven.

The Clean continue to produce music, with Flying Nun recently issuing a comprehensive collection of their previously hard-to-find singles. Output from the band has been sporadic over the years, with members involved in other projects and Hamish Kilgour living in New York. Other projects involving members of the band include The Bats and The Magick Heads (Scott), Stephen, The Heavy Eights (David Kilgour), and The Mad Scene (Hamish Kilgour).

In early 2007, The Clean toured New Zealand on their "Bangers and Mash" tour, during which they celebrated Hamish Kilgour's 50th birthday while playing at "The Studio" in Auckland on Saturday 17 March 2007. Later that same year, the band's best-known incarnation (Kilgour/Scott/Kilgour) reunited for a short East Coast tour of the USA. The tour began in Manhattan, NYC with four shows: an in-store performance at Other Music and a three night stand at the Cake Shop on the Lower East Side. Although the tour officially concluded with a performance at Johnny Brenda's in Philadelphia, the following week the band played an extra show at Maxwell's in Hoboken, NJ, opening for Yo la Tengo at one of the group's annual Hannukah concerts.

In June 2008 a live album recorded during the 2007 New Zealand tour was released in New Zealand on Arch Hill Records, entitled "Mashed". A new studio album, titled ''Mister Pop'' was released on September 7, 2009 on Arch Hill, and on September 8 in the United States on the Merge label.

The Clean announced their first European dates in more than 20 years, supporting the cult U.S band Pavement at Brixton Academy on the 10th of May 2010. They also played at Butlins Minehead on the 14th of May. Other dates on the tour included Amsterdam (May 22), Hamburg (May 23), Berlin (May 25) and Barcelona's Primavera Sound festival (May 29).

Discography

Filmography

1999: ''Scarfies'', in which they are seen performing the song ''Tally Ho!'' in a performance at the Empire Tavern, Dunedin (the line-up for this performance was David Kilgour, Robert Scott, Robbie Yates, and Thomas Bell).

External links

The Clean and David Kilgour discography

MySpace page

Interview at Acetone Magazine

The Clean on Flying Nun Records

Category:New Zealand rock music groups Category:Flying Nun Records artists Category:Musical groups established in 1978 Category:Dunedin Sound

de:The Clean fr:The Clean