- Classes are more modular, as they depend only on the interface of passed-in dependencies. Class behavior can be changed by swapping out a new component.
- Testing is simplified, since stubs can be substituted for any dependency.
- It's harder to understand how a class works when reading just that class. You may have to track down its invocation to see what kind of components are passed in.
- Is DepedencyClass.expects(:new).returns(stub)) a smell, since we should have injected that stub to the class that uses it instead?
- If a class uses DI, should one only pass in already-instantiated dependencies, or is it okay to let the calling class instantiate them?
- Am I missing any pros or cons?
tuker,
"Is the alternative having the code in the class instead of injecting it from the outside?"
Yes. So imagine:
vs.
With the first, you know for sure what the calculator's class will be at runtime just by looking at the Foo class. With the second, you will have to look at the code that instantiates Foo to figure it out. I'd argue this is a con.
As for your comment on the 'do nothing' default, I'm not sure I follow. Can you show what you mean?