Oh, and by the way: death to injection frameworks. I want my java code to be readable, tangible java code.
Oh, and by the way: death to injection frameworks. I want my java code to be readable, tangible java code.
My preference has always been have a constructor which takes in the interfaces required. Its very explicit, makes testing a breeze and with no magic is much easier to read.
The less magic the better.
When you have a strong idea about the direction of the project then you start creating less branches that lead no where.
e.g.: Integration with Twitter. If you don't mocked Twitter client API, you won't be able to write unit-test (or someone will make a lot of excuses of how hard to write unit-tests).
You can work-around DI with having a factory/template method that you'd override or whatnot but that situation won't work 100% in all situations. You may end up writing more code.
YMMV. Use it when you absolutely need it.