Ответ
Нет, Context не должен находиться в UseCase. UseCase — это слой бизнес-логики, который должен быть независим от Android-специфичных компонентов (включая Context). Это нарушает принципы чистой архитектуры и усложняет тестирование.
Если нужен доступ к ресурсам или системным сервисам, их следует передавать через интерфейсы (например, ResourceProvider или SystemServiceWrapper), реализованные в слое данных или presentation.
Пример:
class GetUserUseCase(
private val userRepository: UserRepository,
private val resourceProvider: ResourceProvider // Интерфейс, а не Context
) {
suspend fun execute(): User {
return userRepository.getUser()
}
}Ответ 18+ 🔞
А, блядь, опять про этот ваш Context в UseCase! Ну слушай, я тебе сейчас такую простыню правды впаяю, что ты сам от себя офигеешь.
Ёпта, ну представь себе: у тебя есть повар — это UseCase, да? И он должен готовить бизнес-логику. А ты ему в руки суёшь не только продукты, но ещё и всю кухню целиком — плиту, раковину, холодильник, контекст этот твой. Он что, должен ещё и сантехником быть, и электриком? Нет, блядь! Он повар, его дело — готовить, а не в унитазе прочищать засоры. Так и UseCase — его дело логику выполнять, а не с андроидовским контекстом в заднице возиться.
Это, ёбана, нарушение всех мыслимых и немыслимых принципов! Чистая архитектура, понимаешь? Она как девственница — не терпит, когда в неё лезут грязными руками. А Context из Android — это и есть самая грязная, прикладная хуйня. Как только ты его в UseCase засунешь, всё — прощай, независимость, здравствуй, ебанько на тестах! Потому что теперь твой UseCase привязан к платформе хуй знает как, и протестировать его в изоляции — это пиздец какой квест.
Что делать-то, спрашиваешь? Да всё просто, как три копейки! Нужен доступ к ресурсам? Создай интерфейс ResourceProvider. Нужны системные сервисы? SystemServiceWrapper, на тебе. Эти штуки реализуешь где надо — в data-слое или presentation, и передаёшь в UseCase через конструктор. UseCase будет работать с абстракцией, а не с конкретной андроидовской хуйнёй. И тестировать можно будет, подсунув какую-нибудь заглушку-мок. Красота, а не жизнь!
Вот смотри, как это выглядит, чтобы совсем понятно было:
class GetUserUseCase(
private val userRepository: UserRepository,
private val resourceProvider: ResourceProvider // Вот эта штука, а не Context!
) {
suspend fun execute(): User {
return userRepository.getUser()
}
}Видишь? Никакого Context! UseCase чистый, как слеза младенца. Он про ресурсы знает только то, что ему сказали через интерфейс. А что там под капотом — строки из strings.xml или из облака летят — ему похуй. Его дело — логику гонять.
Запомни раз и навсегда: UseCase — это святая святых бизнес-логики. Туда не лезем с грязными сапогами платформенных зависимостей. Иначе получится не архитектура, а та самая пиздопроебибна, где всё связано со всем, и через полгода сам не разберёшь, что к чему. Доверия к такому коду — ноль ебать. Так что не выёбывайся, делай по-человечески.
