Описываем UseCase’ы правильно

Корни проблемы

Слова usecase и interactor попали в обиход Android-разработчиков из книги про «чистую» архитектуру. Книгу эту почти никто не читал внимательно, плюс изложенные там свойства «чистой» архитектуры сформулированы неточно (многие до сих пор уверены, что «чистая» архитектура — это про то, как на слои абстракций логику делить). Чтобы в них разобраться, нужно прочитать еще пару книг из 90-х, мало кто этим занимается.
Из-за этого я часто вижу в проектах, как разработчики пытаются самостоятельно осмыслить предложенные дядюшкой Бобом правила написания кода и сделать из принципов SOLID конфетку. Этот процесс натыкается на неопытность разработчиков и непонимание того, что такое архитектура в принципе. В итоге код со временем становится менее расширяемым и более связанным.

Призываю читателя не использовать эти абстракции в принципе. Всегда на собеседованиях спрашиваю, есть ли в проекте юзкейсы. Если есть, это в 99% значит, что проект будет комком грязи. НО — если уж эти абстракции везде используются и про них спрашивают на собеседованиях, я хочу предложить своё видение того, как можно их использовать.

Что такое архитектура

Архитектура это набор ограничений и четко определенный подход к обработке ошибок.
Т.е., если на проекте есть архитектура, то есть один способ написания кода, и некорректно написать просто нельзя. Если в твоем проекте можно на ушах стоять — нет у тебя на проекте архитектуры.

Если на твоем проекте ошибки обрабатываются в нескольких местах или их обработка не обязательна — нет у тебя на проекте архитектуры.

Часто совершаемые ошибки

Юзкейсы обычно описывают какую-то мелкую операцию. Под интеракторами подразумевают класс, который «пользуется» несколькими юзкейсами. Этот подход может привести только к фиаско.

Его проблема в том, что он требует огромной дисциплинированности от разработчиков, т.к., чаще всего никто не смотрит на то, написан ли уже юзкейс с нужной тебе логикой и разработчик просто создает свой. Плюс, при таком подходе ничто не мешает добавить в качестве зависимости репозиторий и положить его рядом с интеракторами/юзкейсами. Ничто не мешает какие-то юзкейсы скрыть в интеракторе, а какой-то запровайдить рядом с интерактором.

Таким образом логика реализации бизнес-требований не переиспользуется, а размазывается по приложению. В случае возникновения бага найти место в коде, где возникла проблема, становится очень проблематично и изменение в дата слое может неявно затронуть несколько классов (скептик может возразить «Да ладно, так никто не пишет, нужно совсем тупыми быть»; так вот, уважаемый скептик, ТЫ НЕ ПОВЕРИШЬ, сколько раз я видел подобное даже в командах, состоящих из очень талантливых разработчиков).
Предлагаю от такого кода защититься архитектурным подходом и пересмотром определений.

Как описывать юзкейсы

Юзкейс должен описываться как абстрактный класс, в который провайдятся интерфейсы зависимостей. Таким образом, мы реализуем принцип инверсии зависимостей («модули зависят от абстракций»), и получаем класс, в котором мы можем заменить логику просто заменив имплементацию зависимости (привет, паттерн Стратегия!).

У юзкейса может быть только один публичный метод — operator fun invoke. Таким образом форсится, что за юзкейсом скрывается единственная операция.

Интерактор в таком случае становится конкретной имплементацией абстрактного юзкейса. Это очень важно — интерактор, это не какой-то класс-контроллер, который прячет за собой юзкейсы, а именно имплементация юзкейса. Интерактор, который прячет за собой юзкейсы — абсолютно ненужная абстракция, которая только мешает разбираться в коде и этот код поддерживать.

Talks is cheap, show me the code (© один финский нацист)

Допустим, есть бизнес-требование запрашивать ленту новостей для авторизованных и неавторизованных пользователей с разных API-endpoint’ов.

Пример того, как это описать:

abstract class GetFeedUseCase constructor(     private val feedRepository: FeedRepository, // интерфейс     private val mapper: FeedMapper, // тоже интерфейс ) {     operator fun invoke(): FeedData {         return feedRepository.fetchFeed()             .run(mapper::mapFeed)     } }  // юзкейс запроса данных для авторизованного пользователя class AuthUserGetFeedInteractor constructor(     @AuthRepo feedRepository: FeedRepository, // здесь в имплементации используем бек с авторизационными хедерами     mapper: FeedMapper, ) : GetFeedUseCase(feedRepository, mapper)  // юзкейс запроса данных для неавторизованного пользователя class NonAuthUserGetFeedInteractor constructor(     @NonAuthRepo feedRepository: FeedRepository, // здесь в имплементации дергаем бек без авторизационных хедеров     mapper: FeedMapper, ) : GetFeedUseCase(feedRepository, mapper) 

В данном случае логику запроса данных для авторизованного и для неавторизованного пользователей можно описать, просто запровайдив соответствующие имплементации репозитория и маппера (например, на уровне DI).

В GetFeedUseCase можно добавить логику с кэшированием, отправкой аналитики, да всё что угодно — логика для обоих типов пользователя (описанная в абстрактном классе) будет работать одинаково для всех кейсов (pun intended).

Таким образом у нас появляется единственная абстракция описания единицы логики — юзкейс. Она всегда прячет за собой принятие решений и работу с данными, тем самым облегчается работа с кодом.

Написание тестов на подобным образом описанную логику становится делом тривиальным. Плюс, в тестах можно использовать стабы вместо моков, что всегда плюс.

Как сделать так, чтобы подобные юзкейсы стали «кирпичиками» логики и организовать взаимодействие с родительскими слоями останется упражнением для читателя (всё зависит от принятой на проекте архитектуры и используемых библиотек для описания асинхронных операций, это выходит за рамки статьи).

Спасибо за время, потраченное на прочтение! Открыт для комментариев.

Всем желаю удовольствия от кодинга.