Skip to main content

Inversion of Control Containers and the Dependency Injection ...

Popularity Report

Total Popularity Score: 0
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...

Rank

Bookmark History

Saved by 34 people (1 private), first by anonymouse user on 2006-07-05


Public Sticky notes

Underlying these containers is a common pattern to how they perform the wiring, a concept they refer under the very generic name of "Inversion of Control"

Highlighted by gman_sm

The names I'm using for them are Constructor Injection, Setter Injection, and Interface Injection. If you read about this stuff in the current discussions about Inversion of Control you'll hear these referred to as type 1 IoC (interface injection), type 2 IoC (setter injection) and type 3 IoC (constructor injection). I find numeric names rather hard to remember, which is why I've used the names I have here.

Highlighted by gman_sm

Inversion of Control Containers

Highlighted by microshort

Dependency Injection

Highlighted by microshort

dynamic service locator

Highlighted by navneetk

The main difference is that I expect a component to be used locally (think jar file, assembly, dll, or a source > > i mport). A service will be used remotely through some remot >e > i nterface, either synchronous or asynchronous > >

Highlighted by navneetk

With service locator the application class asks for it explicitly by a message to the locator. With injection there is no explicit request, the service appears in the application class - hence the inversion of control.

Highlighted by navneetk

with a Service Locator every user of a service has a dependency to the locator. The locator can hide dependencies to other implementations, but you do need to see the locator.

Highlighted by navneetk

Dependency injection and a service locator aren't necessarily mutually exclusive concepts.

Highlighted by navneetk

configuration through XML files and also through code

Highlighted by navneetk

In this kind of scenario I don't see the injector's inversion as providing anything compelling.

The difference comes if the lister is a component that I'm providing to an application that other people are writing. In this case I don't know much about the APIs of the service locators that my customers are going to use. Each customer might have their own incompatible service locators

Highlighted by navneetk

Since with an injector you don't have a dependency from a component to the injector, the component cannot obtain further services from the injector once it's been configured.

Highlighted by navneetk

frameworks should minimize their impact upon application code, and particularly should not do things that slow down the edit-execute cycle. Using plugins to substitute heavyweight components does a lot help this process, which is vital for practices such as Test Driven Development.

Highlighted by navneetk

a more general issue with object-oriented programming - should you fill fields in a constructor or with setters.

Highlighted by navneetk

Another advantage with constructor initialization is that it allows you to clearly hide any fields that are immutable by simply not providing a setter. I think this is important - if something shouldn't change then the lack of a setter communicates this very well

Highlighted by navneetk

The problem with classic Factory Methods for components assembly is that they are usually seen as static methods, and you can't have those on interfaces. You can make a factory class, but then that just becomes another service instance. A factory service is often a good tactic, but you still have to instantiate the factory using one of the techniques here

Highlighted by navneetk

Factory Methods

Highlighted by navneetk

start with constructor injection, but be ready to switch to setter injection

Highlighted by navneetk

One case is where you have a simple application that's not got a lot of deployment variation. In this case a bit of code can be clearer than separate XML file.

Highlighted by navneetk

configuration files or code on an API to wire up services

Highlighted by navneetk

the Java world at the moment is a cacophony of configuration files,

Highlighted by navneetk

using aspect oriented ideas with these containers

Highlighted by navneetk

When building application classes the two are roughly equivalent, but I think Service Locator has a slight edge due to its more straightforward behavior. However if you are building classes to used in multiple applications then Dependency Injection is a better choice.

Highlighted by navneetk

My long running default with objects is as much as possible, to create valid objects at construction time. This advice goes back to Kent Beck's Smalltalk Best Practice Patterns: Constructor Method and Constructor Parameter Method. Constructors with parameters give you a clear statement of what it means to create a valid object in an obvious place. If there's more than one way to do it, create multiple constructors that show the different combinations.

Highlighted by zubinkavarana

If you have multiple ways to construct a valid object, it can be hard to show this through constructors, since constructors can only vary on the number and type of parameters. This is when Factory Methods come into play, these can use a combination of private constructors and setters to implement their work. The problem with classic Factory Methods for components assembly is that they are usually seen as static methods, and you can't have those on interfaces. You can make a factory class, but then that just becomes another service instance. A factory service is often a good tactic, but you still have to instantiate the factory using one of the techniques here.

Constructors also suffer if you have simple parameters such as strings. With setter injection you can give each setter a name to indicate what the string is supposed to do. With constructors you are just relying on the position, which is harder to follow.

Highlighted by zubinkavarana

I use component to mean a glob of software that's intended to be used, without change, by application that is out of the control of the writers of the component.

Highlighted by danielgelinas

The main control of the program was inverted, moved away from you to the framework.

Highlighted by sinewmy