В чем разница между Interactor и UseCase?

Разница между Interactor и UseCase в архитектуре Android

В контексте архитектуры приложений, особенно Clean Architecture или MVP/MVI, термины Interactor и UseCase часто используются для описания слоя бизнес-логики. Они являются ключевыми компонентами, отвечающими за выполнение конкретных операций, связанных с данными и бизнес-правилами.

Сходства и общая концепция

Оба понятия представляют объекты бизнес-логики, которые:

• Инкапсулируют конкретную операцию (например, "получение списка пользователей", "создание нового заказа").
• Абстрагируют реализацию от слоя представления (UI).
• Работают с репозиториями или источниками данных для получения или обработки информации.
• Часто возвращают результаты через механизмы реактивного программирования (например, Flow, RxJava, Coroutines).

Ключевые различия в терминологии и практике

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

1. Терминологические традиции и архитектуры

• UseCase — термин, который стал де-факто стандартом в современных реализациях Clean Architecture (по мотивам книги Роберта Мартина). В этой парадигме UseCase представляет собой "правило бизнеса" или "операцию", которую система должна выполнить. Каждый UseCase — это маленький, тестируемый класс с одной четкой ответственностью.

• Interactor — термин, исторически более связанный с VIPER архитектурой и некоторыми ранними описаниями Clean Architecture. В VIPER Interactor — это центральный компонент, отвечающий за бизнес-логику и взаимодействие с репозиторием. Он может быть несколько более "тяжелым" и комплексным по сравнению с UseCase.

2. Степень детализации и объем ответственности

На практике сегодня разница часто сводится к масштабу и детализации:

• UseCase обычно представляет одну, максимально конкретную операцию. Например, GetUserByIdUseCase, LoginUserUseCase, RefreshTokenUseCase. Принцип "один UseCase — одна задача" является строгим.

class GetUserByIdUseCase(
    private val userRepository: UserRepository
) {
    suspend operator fun invoke(userId: String): Result<User> {
        return userRepository.getUserById(userId)
    }
}

• Interactor в некоторых старых или менее строгих реализациях мог объединять несколько связанных операций в одном классе. Например, UserInteractor, который содержал методы getUserById(), loginUser(), updateUserProfile().

// Пример более "широкого" Interactor (не рекомендуется в современных чистых реализациях)
class UserInteractor(
    private val userRepository: UserRepository,
    private val authRepository: AuthRepository
) {
    suspend fun getUserById(id: String): User { ... }
    suspend fun login(email: String, password: String): Result<Unit> { ... }
}

3. Современная практика и рекомендации

В современных Android-проектах с Clean Architecture предпочтительной и наиболее распространенной практикой является:

• Использование термина UseCase.
• Следование принципу Single Responsibility Principle для каждого UseCase.
• Инъекция зависимостей (обычно репозиториев) через конструктор.
• Использование invoke operator или явного метода execute() для запуска операции.
• Возврат данных через корутины (suspend) или Flow.

Выводы и рекомендации для собеседования

На собеседовании важно показать понимание концепции, а не терминологической путаницы:

• Суть: Both Interactor и UseCase служат для отделения бизнес-логики от UI и данных. Они являются "рабочими" слоя Domain.
• Современный стандарт: В 95% современных проектов вы будете встречать термин UseCase в его "чистой", однооперационной форме.
• Ключевые атрибуты хорошего UseCase/Interactor:

    * Не зависит от фреймворков Android (не содержит `Context`, `View`).
    * Является легковесным, тестируемым классом.
    * Взаимодействует только с репозиториями или другими UseCase.
    * Не содержит логики представления или логики сохранения данных (это для Repositories).

Таким образом, можно ответить: "В современной Clean Architecture эти термины практически синонимичны. UseCase — это более популярный и конкретный термин для класса, выполняющего одну бизнес-операцию. Interactor — исторический термин из VIPER, который в чистой реализации должен быть таким же однофункциональным, как UseCase. Главное — понимать их роль как инкапсуляторов бизнес-правил, независимых от UI и фреймворков."