Can I override a binding in dagger?

Question

If I have a default impl of a class, and it does define @Inject constructor, that's great. The system picks it up.

If one app wants to override that default impl with a subclass, I can define an @Provides in its module and call "new" on that subclass in my own code, and dagger uses that impl instead (from what I can tell so far, this works).

However, if I want dagger to instantiate that subclass, it there a way to do it without declaring "override=true" in the @Module? I like not having the override=true so that all the duplicate checks at build time give me appropriate warnings.

One way to do it, of course, it to force all apps to declare the @Provides directly. That just adds to the bloat.

I've used GIN (Guice for GWT) before, and you can define a binding to the class you want by a .class reference, but I don't see anything similar in dagger.

Answer 1

Right now, there is no way to have a "default binding" which you can freely override, without using the "overrides" attribute (which was intended more for testing than this.) We are considering how to do default bindings.

You might consider using a set binding to do this, by having something like along these lines:

@Module(...)
class MyModule {
  @Qualifier @interface OverridableFoo { }

  @Provides(type=SET_VALUES) @OverridableFoo Set<Foo> provideOverriddenFoo() {
    return new HashSet<Foo>(); // Empty set to ensure the Set is initialized.
  }

  @Provides Foo provideFoo(@OverridableFoo Set<Foo> Foo overriddenFoo) {
    switch (overriddenFoo.size()) {
      case 0: return new DefaultFooImpl();
      case 1: return overriddenFoo.iterator().next();
      default: throw new IllegalStateException("More than one overridden Foo Provided.");
    }
  }
}

Then, when you want to override, you simply include this:

@Module(...)
class MyModule {
  @Provides(type=SET_VALUE) @OverridableFoo Foo provideBetterFoo() {
    return new MyAwesomeFoo();
  }
}

This is not a great way to go, as it moves what should be a compile-time error to run-time, but as a stop-gap while we attempt to decide how to handle default bindings, I think it is workable.