Abstraction is really really really hard, sometimes fruitless, and often slower than just bespoke solutions

Yep. Which makes me worried when I need to wade through 12 different new concepts (which turn out to be layers of fluff around an IdentityHashMap, thanks for nothing Hibernate Cache!)

Same goes for Spring these days.

Yes, they take repetitive work away from you. No, they will make you pay interest on those savings the moment you want to debug some obscure issue.

@mbickel: however, I've created a successfull project using such layered architecture. I haven't encountered leaking abstractions. When I had problems with performance, I analyzed query log and found a bottleneck. Yes, I had to optimized such things, sometimes I had to reorganize code in business layer, which still had no direct knowledge of persistence. Poor performance of ORM is a myth

But my point is you had that knowledge. It's part of the architectural debt of the application. If you hand your application to me, and I happily go about adding functionality I need to know about your persistence layer or I will add poorly performing extensions to it.

why i switched from scala to asm

But is dependency management at runtime really a good thing? Why can't I know ahead of time.

I think dependency injection doesnt means knowing only in runtime (ie: don't inject interfaces but the implementation itself is possible.

but interfaces allows looser coupling which is sometimes good

I was working with guice and was very happy with it

@jkbbwr: DI doesn't have to be runtime, like I said, Dagger 2 is 100% static.

(I still prefer Guice for a couple of reasons myself, but Dagger is pretty much the standard on Android)

Hmm.

Maybe I just need a good long sitdown and fiddle.

That or I need to see a real non-trivial example.

I find the examples used are quite contrived

Isn't the testing aspect compelling on itself? I can write a test about pretty much any class in my system, regardless of how deep it is. I just inject it in my test and I call methods on it.

wrt. Dagger 2 as far as I’ve been able to tell it doesn’t do anything special to aid with testing, and there are a bunch of outstanding issues on the github basically saying as much. As far as I’ve been able to tell if you want to switch out the object you are testing you need some kind of a swappable singleton pattern, which is the same way it would be done without Dagger 2. I would be interested to hear if there is a more reasonable way to address testing with Dagger 2 though.

you can configure testmodules which override certain instance providers

and then use those modules instead of the production ones

same goes for "demo mode" kind of applications

where you would swap out your production module with one that provides mock data or smth

I'm using dagger 2 for a relatively complex app and I'm not looking back

@dalexander: They actually state that you shouldn't use dagger to test, just pass plain old instances. Which is funny

Why do I need this complex tool to set me up an instance when I can just pass instances that it cares about to it

I’m not making the argument it isn’t useful (I’m probably going to use it on my next project), but rather than it isn’t good for all the things it’s claimed to be good for. Although looking at the documentation I’m not sure if I can find a reference to how to swap out the real module with the test module, is that something that happens in the build layer?

@jkbbwr: depends on the level of testing... of course you wouldn't use dagger 2 for unit tests

but you might want to replace network stuff for UI tests

Well, if you are manually DI’ing everything stuff will get out of control pretty quickly (I’ve seen constructors with 20+ arguments on a particular project because they were passing in every possible dependency)