Распространенные ошибки в шаблоне UseCase для Android

Я часто сталкиваюсь с неправильным использованием паттерна UseCase в Android-разработке. Хотя UseCase широко используются во многих приложениях, разработчики часто применяют их не по назначению.

Что такое UseCase

UseCase — это инструменты, которые помогают организовать сложную логику приложения в простые, многократно используемые части. Думайте о них как о контейнерах, в которых хранятся определенные задачи или операции, которые должно выполнять ваше приложение. Они следуют основному правилу программирования: каждый UseCase должен делать что-то одно и делать это хорошо.

Вот основные преимущества использования UseCases:

• Способствует повторному использованию кода в различных частях приложения
• Отделяет бизнес-логику от деталей реализации для лучшей организации
• Улучшает тестируемость за счет изоляции сложных бизнес-операций
• Обеспечивает модульную архитектуру, которую легче поддерживать и модифицировать.

Распространенные ошибки при реализации

В Android-разработке я заметил две распространенные ошибки:

• Внедрение строгого доступа ViewModel только к UseCase
• Создание сопоставлений «один к одному» между методами Репозитория и UseCase.

1. Строгий доступ ViewModel к UseCase

Распространенный шаблон реализации строго устанавливает, что ViewModel может обращаться только к UseCase, полностью ограничивая прямой доступ к Репозиторию. Хотя такой подход является частью паттерна Domain Layer, команда Google Android рекомендует сделать его необязательным. Это решение должно зависеть от конкретных требований вашего приложения.

Такое ограничение часто приводит к росту числа классов UseCase. Например, если у репозитория есть 10 методов, то в итоге вы создадите 10 соответствующих UseCase. В сценариях, когда ViewModel требуется большая часть функциональности репозитория, инжектирование одного хранилища будет более эффективным, чем инжектирование нескольких UseCase.

2. Сопоставление методов один к одному

Вторая ошибка связана с созданием UseCase, которые просто проксируют методы Репозитория. Например, создание GetUserUseCase, который вызывает и возвращает только метод getUser хранилища. Иногда разработчики добавляют простой маппер, но по сути сохраняют те же отношения «один к одному». В таких случаях прямой доступ к хранилищу из ViewModel будет более уместен.

Правильная реализация UseCase

UseCase специально разработаны для обработки сложной бизнес-логики. Вот пример хорошо реализованного сценария использования из документации Google по Domain Layer:

/**
 * This use case fetches the latest news and the associated author.
 */
class GetLatestNewsWithAuthorsUseCase(
  private val newsRepository: NewsRepository,
  private val authorsRepository: AuthorsRepository,
  private val defaultDispatcher: CoroutineDispatcher = Dispatchers.Default
) {
    suspend operator fun invoke(): List<ArticleWithAuthor> =
        withContext(defaultDispatcher) {
            val news = newsRepository.fetchLatestNews()
            val result: MutableList<ArticleWithAuthor> = mutableListOf()
            // This is not parallelized, the use case is linearly slow.
            for (article in news) {
                // The repository exposes suspend functions
                val author = authorsRepository.getAuthor(article.authorId)
                result.add(ArticleWithAuthor(article, author))
            }
            result
        }
}

Этот UseCase демонстрирует правильную реализацию, объединяя данные из нескольких хранилищ и выполняя бизнес-логику для создания новой модели.

Рекомендация Google

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

Заключение

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

Более подробную информацию о рекомендациях Google по использованию доменного слоя можно найти в их официальном руководстве.

Источник