Комментарии 17
Спасибо за статью!
Полностью согласен! Если UseCase является прокси объектом к другому механизму(репо например) или содержит минимальное кол-ло логики, то выделение UseCase приводит лишь к дополнительным тестам, а учитывая, что репо это внепроцессная зависимость, то по-хорошему и к дополнительным тестовым дублёрам(моки, фейки и т. п.).
Не люблю юзкейсы - конструктор класса возвращает совсем иной объект. Глаза режет)
А добавьте туда высокие требования к ясности названий как классов, так и получаемых переменных. Тут и без юзкейсов зачастую беда с неймингами. А тут смотришь на их применение в коде и в голове крутится - "Что ты такое?"
Что-то вы путаете. Как ни крути, но конструктор класс по прежнему возвращает instance этого класса. А вот уже сам instance можно вызвать после этого с другими параметрами.
Смотри, попутал на ночь глядя)
С конструктором все ок, но все равно выглядит странно. Не могу привыкнуть к ним. К тому же, те примеры, что я видел на практике были не совсем удачные, в отличии от того что тут приведен
Согласен, что выглядит странно, особенно если так написать )):SomeUseCase(someRepository)(someId)
Но можно же и явно вызвать метод invoke
Боюсь с этим мало что можно сделать, современные тенденции, они такие )
в контексте юзкейсов думаю это оправданно. такой подход подталкивает пооектировать их только с одним публичным методом. и странно конда имя useCase совпадает именем метода.
плюс в реальном мире врят ли увидишь приведенную запись. так как скорее всего будет какойто di
Как сложно =) На самом деле если вы используете иньекцию зависимостей, то в вашу VM придёт переменная someUseCase: SomeUseCase. А потом вы ее вызовите как будто бы обычный метод someUseCase(someID). И выглядит совсем не страшно) Ну и invoke если уж совсем явно хотим.
Использование use case везде — это вынужденная мера для сохранения единого стиля, консистентности и архитектуры. Если никто не запретит использовать repository напрямую, то на одном экране будут использованы use case, на другом repository во view model. А на третьем, однажды, вообще решат, что view model — ни к чему, можно запросы дергать из UI кода. Архитектура — есть архитектура. Рассуждения о том, что где-то лишнее приводит лишь к халиварам.
Если вопрос в том, что для простого приложения, по типу todo list, не нужно использовать use case, то соглашусь. MVP Todo list не предполагает логики кроме получения списка и добавления новой записи. Но позже, вероятно, может потребоваться расширение. В таком случае, для выстраивания архитектуры может быть необходимость какой-то код перенести в use case. А для того, чтобы код был идентичен, придется везде мигрировать на use case.
Активно использую useCase - выношу в них все что можно и ничего в этом страшного нет. Да 90% из них так и остаются одноразовыми и закрытыми фичами. Зато это чистое ООП, где на каждую задачу еть свой выделенный класс. Главная задача useCase-ов уменьшить кодовую базу и облегчить тестирование. Если у вас все в едином файле на 2к сипрк, работать с этим сложно, а покрывать такую логику unit тестами вообще больно, если не невозможно. Так что лучше useCase-ов пока ничего не видел. Позволю себе привести здесь пример своего опен-сорсного проекта где useCase-ов на каждый чих (https://github.com/georrge1994/polykek-schedule-app/tree/main). Проекты же, где от них отказались выгледят крайне"замусоренными" и неаккуратными
Проблема UseCase-ов: что нужно знать разработчикам Android