отвечать за бизнес логику, а цепочка выполнения - она самая.
Чем дублирование кода лучше реюзания интракторов? Самовынуждение фиксить один флов в двух местах равно выстрелу ногу.
Так если логика в скоупе интекрактора сменилась, а другому интерактору она нужна проапдечена, то это же наоборот удобно.
Можно конечно кусок логики вынести из интерактора, и назвать его "сервисом" но суть от этого не меняется, лишь больше классов и кода.
А если кусок логики не нужен другому интерактору, и изменение этого куска влечет за тем, что появятся неявные баги из-за неявных зависимостей?
Если у вас цепочка выполнения - это бизнес логика, то это тянет на отдельный юзкейс, как я и писал выше. Если же это просто последовательное выполнение, не завязанное на бизнес логику, то ничего странного в выполнении в презентере нет. При правильной архитектуре дублирование кода будет завязываться лишь на вызове тех же методов из следующего слоя, а вот вызовы интеракторов друг из друга никак не обезопасить, это в любом случае лишняя зависимость. Да, а если логика в скоупе интерактора изменилась, а другому интерактору нужна старая? Кто будет за этим всем следить? Даже если вынести это в доку или еще куда, шанс того, что кто-то забудет или не будет знать об этом слишком велик. И чем «больше классов и кода» плохо, если оно помогает решать проблему?
Обсуждают сегодня