Комментарии 6
Спасибо, за статью, автор очень хорошо раскрыл тему. А можете объяснить, зачем вы создаёте интерфейс FetchMemesUseCase, который имеет только одну реализацию. Я где-то читал, что в таком случае интфейс не нужен.
Ну как минимум чтобы другие юзкейсы/вьюмодели не зависили от конретной реализации, таким образом проще тестировать конкретные участки кода.
Также если мы создаем интерфейсы в условном api модуле фичи, а реализации уже в domain, то тогда другие domain модули из других фичей не зависят от нашего domain модуля и в обратную сторону также. Тем самым мы можем использовать юзкейсы в юзкейсах других фичей и не париться о кроссзависимостях между модулями. (Также тут могут образоваться зависимости между тем, что юзкейсы зависят друг от друга, но тогда это неправильная логика просто)
Никогда не понимал, зачем делать одострочные юз кейсы.
Вот зачем сначала делить на 3 юз кейса, а потом собирать их в один провайдер? Чтобы что? Усложить себе и своим коллегам поддержку? Их можно переиспользовать где-то отдельно, а не в связке? - очевидно, нет. Они будут изменяться отдельно, а не в связке? - очевидно, нет.
Единственная причина так делать в этом конкретном примере - принцип ради принцпиа, доведенного до абсурда. Это же просто софистика: можно сказать "у нас разные отвественности - оплата, проверка, возврат", а можно сказать "у нас ответственность - работа с платежами". Поддерживать, тестировать и применять 1 интфейс с 2 реализациями проще, чем 3 интерфейса и 6 реализаций соответственно. Они же в геометрической прогрессии плодятся.
Приходишь на проект, а там десятки этих юз кейсов с одним инвоком. И думаешь: "Ну вот нахрена?" Кучка из юз кейсов работает в одной вью модели, с одним репозиторием, с одной сущьностью, больше нигде не используются. В умной статье так написано делать?
Я считаю, что принцип единой ответственности надо применять разумно, а не высасывать из пальца якобы "разную ответственность", где её по факту может и не быть.
Согласен на 100%. Они даже объединенные очень редко практический смысл имеют, ибо выступают как прокладка к репозиторию, в итоге 95% все что делают - дергают репозиторий и возвращают его ответ. А уж куча интерфейсов по одному методу каждый из которых все что делает репозиторий вызывает (который тоже еще "абстрагирован" интерфейсом)... Получается оверинжиниринг ради оверинжиниринга. Про KISS все забыли помешавшись на clean и SOLID. Да, если репозиторий жирный (или есть неплохие шансы что разжиреет) - действительно слой абстракции вполне гуд внести. Но и то, ничего не мешает сделать интерфейс с нужными для домена/UI методами, и заставить непосредственно репозиторий его имплементировать. По крайней мере если у вас не проект над которым работают 20+ человек, а типичное приложение, что разрабатывается 1-3 людьми.
Вообще абстрагировать фичи стоит. Через модули (api модуль для взаимодействия с другими модулями, сама реализация в impl модуле, чтобы другие модули не использовали внутрянку нашего). Это смысл имеет вполне себе. Особенно когда/если понадобится переводить на kmp. Но в рамках модуля, если он сам по себе не разрастается больше 3-5к+ строк - высокую связность иметь вполне норм (опять же, не до абсурда). А уж если одной фиче требуется чтобы модуль другой фичи что то сделал - тут да, можно уже выделять юзкейсы минималистичные через api. И получаем классическое low coupling/high cohesion без оверинжиниринга.
Дополню еще про
Это же просто софистика: можно сказать "у нас разные отвественности - оплата, проверка, возврат", а можно сказать "у нас ответственность - работа с платежами".
Насколько помню изначально дядя Боб под ответственностью вообще имел в виду актора от которого требования пришли. Условно, вот есть бухгалтер. От него такие то требования к системе. И модуль/юнит кода который отвечает за эти требования не должен отвечать за чьи то еще требования. Это уже потом оно тысячу раз переварилось и к текущему пониманию пришло.
Почему БИЗНЕС-логика, она же реализация юзкейса - лежит в слое данных?
Ликбез по UseCase’ам Android: от базовых реализаций до мультипровайдерных и многомодульных систем — Часть 1