Привязка без области видимости в модулях против привязки, внедренной конструктором в Dagger

Question

У меня есть привязка с незаданной областью внутри appModule и тот же класс, что и конструктор, введенный с использованием области Singleton. когда я добавляю объявление внутри appComponent для Foo, сгенерированный код берет привязку модуля без каких-либо DoubleCheck т.е. привязка с незаданной областью через конструктор, введенная привязка Singleton, почему это так?

      @Module
public class AppModule {

     @Provides
     public Foo provideFoo() {
         return new Foo();
     }
}

@Component(module = AppModule.class)
@Singleton
public interface AppComponent {
     Foo getFoo();
}

@Singleton
class Foo @Inject constructor(){
     //..
}

Answer 1

Существует некоторая иерархия в том, как предоставляются зависимости, я еще не нашел документации по этому поводу, но я тоже столкнулся с тем же самым. Если я правильно помню из своего тестирования, иерархия того, откуда Dagger пытается получить зависимость, следующая:

1. Связанные экземпляры (с помощью методов компоновщика компонентов, например, @BindsInstance)
2. Предоставление модуля
3. Внедренные в конструктор классы

Где-то в этом списке, вероятно, также должны быть включены подготовленные зависимости (предоставленные из родительского компонента, от которого зависит ваш компонент), но я не знаю, где он будет тогда в иерархии.

Обычно нет необходимости предоставлять одну и ту же зависимость несколькими способами, почему вы оба хотите предоставлять зависимость через модуль и через внедрение конструктора? Если есть несколько зависимостей, но они находятся в другой области, попробуйте использовать разные области вместо одной.

Я могу придумать одну причину, по которой вы хотите использовать этот механизм, и это когда вы обычно хотите, чтобы определенная зависимость предоставлялась через конструктор или внедрение модуля, но специально для тестовой сборки вы хотите перезаписать эту зависимость другой зависимостью. путем изменения того, как компонент составляется в тестовой сборке (т. е. затем изменяя DaggerComponent, чтобы он требовал, чтобы метод @BindsInstance перезаписал зависимость по умолчанию тестовой зависимостью).