BT

InfoQ Homepage Presentations Dagger: A Fast Dependency Injector for Android and Java

The next QCon is in London, Mar 4 - 6, 2019. Save an extra £75.00 with INFOQ75!

Dagger: A Fast Dependency Injector for Android and Java

Bookmarks

Bio

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

About the conference

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.

Recorded at:

Feb 07, 2013

Hello stranger!

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

Get the most out of the InfoQ experience.

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

Community comments

  • Good

    by marc prades /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    so why use that over guice for instance ?

  • DI - an Anti-Pattern?

    by Fred Amiter /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: DI - an Anti-Pattern?

    by Oliver Weiler /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The value is that the DI container gets rid of the factory boilerplate code which you have to write by hand. Other than that, I agree with your points.

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

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

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.