Now with more Provost! (p&p, day 3)

There is a distant possibility that I might, utterly unlike last year, "get" Dependency Injection Frameworks.

"Don't call us, we'll call you."

The responsibility for making decisions about how to resolve the dependencies lies outside the object itself.

Service Locator: not really DI, just a pattern. It knows how to find its dependencies.

Interface Injection: the framework can find the inject method, then you pass in an interface.

Setter Injection: call "setFoo" and pass it a Foo.

Constructor Injection: this component requires a Foo, or I can't even "new it up". It doesn't have any limbo state while it's being instantiated/set up.

Others

Method Call/Method Injection: calls methods on your behalf at predefined times.

Getter Injection (AOP): all usage of the Foo inside of the object will call the get(), whose implementation is empty, and the get() gets replaced with an implementation via AOP.

So... why?

Makes you think about highly cohesive, loosely coupled design. Testable without fancy mocking frameworks. Don't Repeat Yourself.

Issues

• Lots of little objects (pitter-patter of little objects?)
• Interface explosion
• Runtime wire-up complicated, difficult to visualize (but he blames the tools more than the technique)
  
• When building reusable libraries, consider wrapping facades around systems created this way
• Late-time binding affects performance, as do all strategies for maintainability; "we all want responsiveness, most of us don't need performance."
  

Scott says, less talk, more code.

Factories are a very specific type of DI.

And now, pair bantering, I mean programming.

"And thus you can destroy, or not destroy, planets."

In conclusion, I get it, but only kinda. Contextualization!