Комментарии 4
Спасибо, за статью, автор очень хорошо раскрыл тему. А можете объяснить, зачем вы создаёте интерфейс FetchMemesUseCase, который имеет только одну реализацию. Я где-то читал, что в таком случае интфейс не нужен.
Ну как минимум чтобы другие юзкейсы/вьюмодели не зависили от конретной реализации, таким образом проще тестировать конкретные участки кода.
Также если мы создаем интерфейсы в условном api модуле фичи, а реализации уже в domain, то тогда другие domain модули из других фичей не зависят от нашего domain модуля и в обратную сторону также. Тем самым мы можем использовать юзкейсы в юзкейсах других фичей и не париться о кроссзависимостях между модулями. (Также тут могут образоваться зависимости между тем, что юзкейсы зависят друг от друга, но тогда это неправильная логика просто)
Никогда не понимал, зачем делать одострочные юз кейсы.
Вот зачем сначала делить на 3 юз кейса, а потом собирать их в один провайдер? Чтобы что? Усложить себе и своим коллегам поддержку? Их можно переиспользовать где-то отдельно, а не в связке? - очевидно, нет. Они будут изменяться отдельно, а не в связке? - очевидно, нет.
Единственная причина так делать в этом конкретном примере - принцип ради принцпиа, доведенного до абсурда. Это же просто софистика: можно сказать "у нас разные отвественности - оплата, проверка, возврат", а можно сказать "у нас ответственность - работа с платежами". Поддерживать, тестировать и применять 1 интфейс с 2 реализациями проще, чем 3 интерфейса и 6 реализаций соответственно. Они же в геометрической прогрессии плодятся.
Приходишь на проект, а там десятки этих юз кейсов с одним инвоком. И думаешь: "Ну вот нахрена?" Кучка из юз кейсов работает в одной вью модели, с одним репозиторием, с одной сущьностью, больше нигде не используются. В умной статье так написано делать?
Я считаю, что принцип единой ответственности надо применять разумно, а не высасывать из пальца якобы "разную ответственность", где её по факту может и не быть.
Ликбез по UseCase’ам Android: от базовых реализаций до мультипровайдерных и многомодульных систем — Часть 1