интересно то, что автор книги когда работал в майкрософте несколько лет пилил свой проект - как раз локатор сервисов) но потом сам же признал его антипаттернов, в отличие от того же фаулера и свернул проект)

только недавно читал в книге Чистый код о том, что чем меньше аргументов у функции тем она лучше

т.к. проще тестировать е

поэтому внедряя в поля вроде как меньше аргументов, это хорошо.

когда много параметров в конструкторе проблема не в том, что много аргументов, а проблема в том, что много зависимостей, внедрения через поля эту проблему никак не решает, возможно только маскирует

Я, например в презентер только инжект вью делаю через конструктор, остальное полями - чем это грозит?

Хотя, я, кажется, немного не понял о чём вы тут говорите))

Кстати,вот если пытаться сделать "правильный" DI. То схема с 1 activity - 1 component более правильная получается,не?

Зависит от задачи

действительно зависит от задачи, я сейчас пришел к схеме один презентер - один компонент, мне кажется, что здесь нужно руководствоваться жизненным циклом компонентов, по правилу - AppComponent - все зависимости (имеется ввиду предоставленные этим компонентом, не считая родительских компонентов) живут пока живет App, UserFragmentComponent - все зависимости живут пока живет UserFragment, UserComponent - все зависимости живут пока живет User, UserPresenterComponent - все зависимости живут пока живетUserPresenter. Так как у меня презентер переживает активити или фрагмент, т.е. отличается его жизненный цикл от активити, то у меня на презентер свой компонент

но эту схему только обкатываю, использую @Subcomponent

Сабкомпонент ломает инкапсуляцию рутового коспонента?

не совсем понял, например?

Ну если я делаю свой компонент

Которому в dependency прописываю рутовый

не не

там не так

там наоборот

в рутовый прописываешь сабкомпонент

Тогда я могу из него вытянуть только то,что объявлено в компоненте