Заблуждение UseCase: что нужно знать Android-разработчикам

Введение

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

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

Противоречивая правда об UseCases

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

Слишком многие разработчики относятся к UseCase как к требованию, что приводит к появлению избыточного и ненужного кода. В результате, вместо того, чтобы сделать свои приложения более удобными в обслуживании и масштабируемыми, они создают раздутые кодовые базы, наполненные слоями абстракций, которые не служат реальной цели.

Когда следует избегать UseCase: сохраняйте простоту

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

Пример: Получение данных из репозитория

Представьте, что вы создаете простое приложение, в котором вам нужно получить список задач из локальной базы данных. Действия просты: вы запрашиваете репозиторий, получаете список и отображаете его в пользовательском интерфейсе.

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

class TaskViewModel(private val repository: TaskRepository) : ViewModel() {
    val tasks = liveData {
        val taskList = repository.getTasks()
        emit(taskList)
    }
}

Почему здесь не нужно использовать UseCase? Потому что он не добавляет ценности. Логика и так проста, и введение UseCase только раздует код без какой-либо явной пользы. Чистая архитектура выступает за простоту и ясность, а UseCase в данном случае сделает все наоборот.

Когда UseCase необходим: обработка сложной бизнес-логики

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

Пример: Бронирование рейса в туристическом приложении

Рассмотрим сценарий, в котором пользователь бронирует авиабилет в туристическом приложении. Этот процесс включает в себя несколько этапов:

1. Проверка вводимых пользователем данных (даты, пункты назначения)
2. Проверка наличия рейсов
3. Резервирование рейса
4. Обработка платежа
5. Отправка подтверждения бронирования

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

UseCase в этом сценарии имеет смысл. Инкапсулируя процесс бронирования в UseCase, вы можете:

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

class BookFlightUseCase(
    private val flightRepository: FlightRepository,
    private val paymentProcessor: PaymentProcessor
) {
    suspend operator fun invoke(flightId: String, userDetails: User, paymentInfo: PaymentInfo): BookingResult {
        if (!validateInput(userDetails)) throw InvalidInputException()
        val availability = flightRepository.checkAvailability(flightId)
        if (!availability) throw FlightNotAvailableException()

        val reservation = flightRepository.reserveFlight(flightId, userDetails)
        val paymentResult = paymentProcessor.processPayment(paymentInfo)

        return BookingResult.Success(reservation, paymentResult)
    }
}

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

Настоящее назначение UseCase: избегать разрастания, а не создавать его

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

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

Заключение: UseCase — это инструменты, а не правила

Главный вывод заключается в следующем: UseCase — это инструменты, а не правила. То, что Чистая Архитектура предлагает их, не означает, что они должны применяться повсеместно. Чрезмерное использование UseCases, особенно в ситуациях без сложной бизнес-логики, приводит к ненужной абстракции и раздутому коду.

Решая, реализовывать или нет UseCase, спросите себя:

• Существует ли бизнес-логика, которую необходимо отделить от слоя представления?
• Будет ли эта логика повторно использоваться в других частях приложения?
• Нуждается ли эта логика в независимом тестировании?

Если ответ на эти вопросы отрицательный, пропустите UseCase и упростите свой код. Если же ответ «да», то UseCase поможет вам добиться более чистой и удобной в обслуживании кодовой базы.

Используйте UseCase с умом, и вы окажетесь на верном пути к написанию чистого и эффективного кода для Android.

Спасибо, что читаете, и удачного кодинга!

Источник