Кстати так и было, я и написал что-то типа «своего

Question

Кстати так и было, я и написал что-то типа «своего

мокси». Даже планировал это в библиотеку выделить.
Но потом, когда релизнули ViewModel ахритектурных компонентов, забил, и переехал на него )
Вот только не пойму, какие именно 2 сущности тут сливаются?
Вот есть фрагмент, который имеет доступ к вьюхам и событиям о действиях пользователя.
Есть некая логика представления (чисто представления, никакой бизнес-логики), которая жонглирует представлением и событиями от него, и которую нужно куда-то поместить.
И тут 2 варианта:
1. поместить её в сам фрагмент/активити. Забиваем на тесты, избавляемся от лишнего слоя.
2. поместить её в отдельный презентер. Тогда фрагмент/активити становятся просто тупыми проксями (пробрасывают команды для View и события). Зато можем логику представления тестировать.
Ну а если у вас в презентерах намешана и логика представления, и логика юзкейсов (первый признак - презентеры знают о репозиториях, и общаются с ними напрямую), то тут уж извините, ваши презентеры уже сами по себе нарушают SRP. А если логика представления еще и размазана между презентерами и фрагментами/активити (то есть они - не тупые прокси), то и еще один набор сущностей у вас нарушает SRP.
В таком случае да, согласен, перенос кода из презентера в фрагмент/активити - это шаг назад к примерам гугла, потому как бизнес-логика просочится и смешается с остальной частью логики представления.
Кстати, описанную ситуацию я видел в бою на нескольких проектах: когда логика представления размазана между презентерами и фрагментами, а бизнес-логика между презентерами и репозиториями. Причем размазано настолько равномерно, что рефакторинга на полгода вперед хватит…
Не берусь сказать, обычная это практика (best practices) или нет, но хочется верить в лучшее - в то, что в серьезных проектах границы слоев соблюдаются максимально строго =)

#it #programming #russian #software

0

19.04.2018

1 ответов

13 просмотров

Алексей Ершов · Accepted Answer

"поместить её в сам фрагмент/активити. Забиваем на тесты, избавляемся от лишнего слоя." - это и есть размазывание ответственности. View - это конкретная реализация отображения. Оно знает, как работать со всеми контролами, как ловить действия пользователя, как отображать ошибки, в какой цвет красить что, и когда передать события презентеру. Presenter - это логика отображения. Он знает, как реагировать на события пользователя, он знает, какие интеракторы когда звать, он знает, как превратить то, что пользователь набил в UI в модель данных уровня бизнес-логики. И ему почти наплевать на жизненный цикл, он знает только attach-detach. И ему всё равно, какие UI-контролы вы используете. Если у вас этим занимается одна и та же сущность - у вас нарушен SRP, и в активити дофига кода, который сложно поддерживать.

214 похожих чатов

Кстати так и было, я и написал что-то типа «своего

1 ответов

Похожие вопросы