[chris_wot]

The direct opposite of Dependency Injection is the Service Locator pattern.

    my_blah = container.resolve(Blah)

Notice how there is no injection of dependencies at all.

I think you aught to learn what DI actually is... when you say that "the single greatest benefit (possibly, only benefit) that DI provides over other service location options" you are saying that DI is a form of service location (sic), which isn't the case.

[_pmf_]

> The direct opposite of Dependency Injection is the Service Locator pattern.

You're right in spirit, but the direct opposite of dependency injection is obviously direct dependency construction, not service location.

Service location is one step up from direct dependency construction, and can be enough for a lot of cases, but as you say, it's not dependency injection.

[chris_wot]

You're right in spirit, but the direct opposite of dependency injection is obviously direct dependency construction, not service location.

Fair call!

[Lapsa]

another thing - there are multiple ways to inject dependencies - not just constructor injection.

[shadowmint]

:)

hint: the DI is in the constructor to Blah when the container returns an instance. (all IOC frameworks have a top level resolve call somewhere).

[chris_wot]

Yeah, to startup the container and manage the object graph, sure. But not to directly instantiate the objects like you've given in your example!

The whole point behind DI is to decouple objects, any IoC container worth it's salt gets started and works it out for you. You shouldn't need to resolve the individual object.

Another poster noted this is known as composition root, a good explanation can be found here:

http://blog.ploeh.dk/2011/07/28/CompositionRoot/

Note the following:

"A DI Container should only be referenced from the Composition Root. All other modules should have no reference to the container."

Words to live by :-)

[shadowmint]

True indeed, however, the point remains:

IOC is resolving an instance with it's dependencies.

How you do that is irrelevant.

The point is that the action of resolving dependencies is NOT dependency injection.

If you're writing an IOC container, call it an IOC container.

[chris_wot]

Excuse me, but the IoC Container is doing the injecting. That's the whole point.

[quarterto]

aught = something. ought = should.

[chris_wot]

I never realized! Thanks, I'll remember that.