You are now in FULL VIEW
CLOSE FULL VIEW

Dagger: A Fast Dependency Injector for Android and Java
Recorded at:

by Jesse Wilson on Feb 07, 2013 | NOTICE: The next QCon is in New York Jun 10-14, Join us!

Summary
Jesse Wilson introduces Dagger, a dependency injection framework for Java, covering the motivation behind its creation, examples on how to use it and some of the internal details.

Bio

Jesse Wilson develops apps and open source at Square. He's worked on Android, Gson, Guice, Guava, and Shush.

Software is changing the world; QCon aims to empower software development by facilitating the spread of knowledge and innovation in the enterprise software development community; to achieve this, QCon is organized as a practitioner-driven conference designed for people influencing innovation in their teams: team leads, architects, project managers, engineering directors.

Related Editorial

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Good by marc prades

so why use that over guice for instance ?

DI - an Anti-Pattern? by Fred Amiter

This talk demonstrates that DI frameworks actually foster bad design. Creating a monolithic object graph on which everything depends isn't desirable for larger applications. Instead of making injection of static code into modules as easy as possible better seek to create independent modules that can be (re-)used in different contexts. I've come to the conclusion that DI is an Anti-pattern that should be avoided.

Re: DI - an Anti-Pattern? by Nils Kilden-Pedersen

Your title is a bit misleading. DI is not an anti-pattern, far from it, but using magic DI containers certainly is, including, it would appear, Dagger.

What's worse is, there's no point to this hand-waving. It buys you absolutely nothing, and it costs you code clarity and pollutes your classes with annotation dependencies.

Let's take the DripCoffeeModule and remove the annotations. Voila, you just have a perfectly useable class for resolving DI, but without the magic:

class CoffeeApp {
	public static void main(String[] args) {
		DripCoffeeModule mod = new DripCoffeeModule();
		Heater heater = mod.provideHeater();
		Pump pump = mod.providePump(new Thermosiphon(heater));
		CoffeeMaker cm = new CoffeeMaker(heater, pump);
		coffeeMaker.brew();
	}
}


Much, MUCH, easier.

Re: DI - an Anti-Pattern? by Tony Chow

Nils, your code is much easier because your program is much simpler. But few applications consist of single method where all dependencies can be wired up. Let's say you have 20 different places in your application where you need to use Pump. Are you going to new up Thermosiphon in twenty different places? In that case, you just surrendered loose coupling. Maintaining loose coupling in large, multi-layered applications is the purpose of IoC containers.

Re: DI - an Anti-Pattern? by Nils Kilden-Pedersen

I don't think so. I used Spring a short while back in 2004 and I quickly realized that coding in XML was entirely unnecessary. You can do the same wiring in real code. I have yet to see a DI container that adds value beyond the cost of its footprint and learning curve.

Re: DI - an Anti-Pattern? by Tony Chow

I'm not sure why you bring up XML--of course it's unnecessary. Any IoC framework worth its salt nowadays--including Dagger--allow you to do all the wiring in code, and that's the preferred method for most people. Implementing dependency injection yourself has always been an option, but you are writing a lot of boilerplate code, in addition to forgoing extra benefits that many IoC containers give you, such as named registrations, scope control, etc, which I use a great deal.

Re: DI - an Anti-Pattern? by Nils Kilden-Pedersen

I guess my point is that I have yet to see a DI container that adds value, XML or annotations regardless. DI is pretty straight forward and wiring up all that magic is not providing the proper cost/benefit result. IMO of course.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 comments
General Feedback
Bugs
Advertising
Editorial
 InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy