Можно сюда попробовать адресовать вопрос https://t.me/dagger_2
Спасибо! Попробую ) Но ведь это так же архитектурный вопрос, вроде
Там Binds не получится использовать, насколько я вижу, тк реализации не закрыты интерфейсами Но вопрос зачем там заюзали Provides вместо того, чтобы просто поставить Inject в конструкторе - остаётся открытым) Может быть там и нет скрытого смысла, просто не самый оптимальный код?💁🏻♂️
Возможно, кто-то не захотел добавлять даггер в зависимости для Inject в конструктор
А @Provides - это разве не даггер? В модуле есть зависимость на даггер уже.
думаю, говорилось о том, чтобы в классе DetailsSwiftSubMapper, например, не было аннотаций даггера. грубо говоря, чтобы в этот класс не добавлять деталей его предоставления в общем коде программы
Если поставить на конструктор Inject и потом забыть где-то написать Binds со скоупом, то новый экземпляр будет создаваться нечвно при каждом внедрении. Если же не ставить Inject, то проект не будет собираться, пока явно не укажешь как и с каким скоупом. В предыдущем проекте где я работал, отказались от Inject именно по этой причине. Правда потом и от даггера отказались, но это уже другая история.
Вообще отказались от DI фреймворков. Вручную стали вызывать конструкторы.
а что с коином не то?
а как контролировать скоупы и их ЖЦ без DI? не много ли бойлерплейта?
Это дело было в Badoo. Там проект был на 1.5 млн строк, и 700+ фича-модулей. В каждой фиче был свой граф из 10-20 классов. Очень легко их было руками создавать в классе-билдере. Фичи были организованы в деревья - RIBs архитектура - скоуп контролировался предками.
Нет (по крайней мере тогда) безопасности во времени сборки. По этой же причине перешли с Toothpick на Dagger, ещё до отказа от последнего.
Обсуждают сегодня