val interactorD: InteractorD)
class InteractorB
class InteractorC(val interactorA: InteractorA, val interactorB: InteractorB)
class InteractorD(val interactorB: InteractorB, val interactorE: InteractorE)
class InteractorE(val interactorC: InteractorC)
Нет ли тут циклических зависимостей?
А реальный пример можно? А то это слишком синтетически выглядит
Ну замените в названиях A, B, C на что-то из своего проекта, чтобы получилось, например, AuthInteractor, UserInteractor, BillingInteractor, SubscriptionInteractor и т.д.)
Может ли в каком-то проекте UserInteractor включать в себя AuthInteractor и SubscriptionInteractor? Вполне. А SubscriptionInteractor может использовать внутри UserInteractor? Ну тоже можно так сделать для удобства. Вот и циклическая зависимость.
Можно и нужно - разные вопросы. Плюс надо помнить про single responsibility
Так тут как раз single responsibility не будет нарушен: в примере каждый интерактор как раз специально и выделен, чтобы заниматься одной единственной задачей и делегировать несвойственные ему задачи другим интеракторам)
Если есть, оно не скомпилируется, и я порефакторю, чтобы убрать цикл)
Почему не скомпилируется? Вполне скомпилируется, хотя да, там есть цикл, но не очевидный, собственно, я это и хотел показать, как легко не заметить циклическую зависимость даже в очень простом случае из нескольких интеракторов (а в реальном проекте обычно их на порядок больше)
Экземпляр же не получится создать, а если даггер, то он прям ругаться будет. В общем, я просто к тому, что на моей практике проблема циклических зависимостей интеракторов не настолько остро стоит, чтобы ради неё возводить архитектурное ограничение. Если у вас этой проблемы больше - то и ограничение может быть оправдано, вопроса нет)
lateinit же можно)
Ой ужас какой, не пугайте людей на ночь)
А если реализовать этот пример на синглтонах, так оно тогда даже годами в проде работать сможет, пока однажды не вылезет трики стэковерфлоу)
Обсуждают сегодня