5 ms·

I was about to say the same thing myself. For some reason, a lot of developers (including me) go through a phase in which they generalize as much as possible as

I was about to say the same thing myself. For some reason, a lot of developers (including me) go through a phase in which they generalize as much as possible as early as possible. This completely misses the obvious: It is harder to plug into an abstraction, especially a bad one, than it is to do the simplest thing and generalize later, when you need to. Oh, and by the way: death to injection frameworks. I want my java code to be readable, tangible java code.

boyter 15y ago
Totally agree with the death to injection frameworks. Where I work a lot of the devs love to talk about "dependency injection" and ways to have some abstracted thing in .NET handle it for you. 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.
- nigelsampson 15y ago
  Agreed, constructor injection is pretty much the only type of "dependency injection" that makes sense to me. The less magic the better.
ebiester 15y ago
I used to feel the same way, but it's really nice to be able to easily plug in a mock for testing. With autowired in spring, it's really not that bad. The way Grails handles it is pretty nice, actually.
neeleshs 15y ago
May be some of the injection frameworks deserve death, but as a concept, I find it pretty useful to write testable code.
TheCapn 15y ago
Maybe I haven't had that phase yet but I tend to believe it occurs when there isn't a finite plan for how everything will work. You start creating abstract classes with the intention that it will do this or that or even whatchamacallit! When you have a strong idea about the direction of the project then you start creating less branches that lead no where.
hello_moto 15y ago
DI is useful in the situation where you'd like to mock 3rd-party web-service (that usually don't have test environment themselves). 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.

boyter 15y ago

Totally agree with the death to injection frameworks. Where I work a lot of the devs love to talk about "dependency injection" and ways to have some abstracted thing in .NET handle it for you. 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.

nigelsampson 15y ago
Agreed, constructor injection is pretty much the only type of "dependency injection" that makes sense to me. The less magic the better.

ebiester 15y ago

I used to feel the same way, but it's really nice to be able to easily plug in a mock for testing. With autowired in spring, it's really not that bad. The way Grails handles it is pretty nice, actually.

neeleshs 15y ago

May be some of the injection frameworks deserve death, but as a concept, I find it pretty useful to write testable code.

TheCapn 15y ago

Maybe I haven't had that phase yet but I tend to believe it occurs when there isn't a finite plan for how everything will work. You start creating abstract classes with the intention that it will do this or that or even whatchamacallit! When you have a strong idea about the direction of the project then you start creating less branches that lead no where.

hello_moto 15y ago

DI is useful in the situation where you'd like to mock 3rd-party web-service (that usually don't have test environment themselves). 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.