Что такое Entities и UseCase в clean architecture и как их правильно выделять?
До сих пор не могу нормально понять, что такое entities и useCase? Т.е, сами определения entities и useCase понятны, но каждый раз, когда сам для себя пытаюсь определить или найти их в приложении, всё время сам себя путаю, что в итоге получается какая-то каша. Условно, переход на другую Activity - я хочу сделать useCase, т.к в принципе по определению подходит - но ведь это глубоко не так. Объясните пожалуйста дураку. Спасибо
Ответы (1 шт):
UseCase - сценарий действия, 1 функция (класс с функцией execute или же функциональный тип, если юзаешь котлин), который выполняет какая-то бизнес-логику.
переход из 1 активити в другую - это UI логика, поэтому тут юзкейс сделать нельзя.
попробуем разобрать на примере.
у нас есть репозиторий с методом, который возвращает нам массив объектов Студенты getStudents.
в 1 месте нам нужны студенты мальчики, во 2м девочки, в 3ем двоечники, в 4ом отличники.
что мы можем сделать?
мы можем написать лишь 1 ЮзКейс, котоырй будет возвращать нам всех студентов, а в нужных местах мы будем их фильтровать.
если нам понадобиться в 5-ом месте какой-то из этих 4ых отфильтрованных списков - придется опять это делать самому руками.
а можем написать 4 разных юзкейса и забыть про особенности фильтрации. когда нам это понадобиться продублировать, мы ничего не будет фильтровать и возьмем уже готовую реализацию.
почему нельзя обратиться к репозиторию напрямую? ну как бы можно...
но вот в один прекрасный день API, в котором ты брал всех студентов - выключается навсегда, создается новая API и возвращает тебе тех же студентов, но совсем в другой модели ответа.
и вот тебе приходится писать новый репозиторий, заменять его во всех местах, а так же адаптироваться под новую модель... приятного мало, поверь.
и вот мы подходим к entities!
entities - это объект бизнес логики.
по сети тебе приходит одна модель ответа, а твоя задача смапить ее под свою логику. тут ты можешь откинуть ненужные поля в ответе, какие-то вещи (например пол студента, можешь переделать из строки "муж / жен" в enum-класс, можешь отвалидировать сетевой ответ "если что-то не пришло - значит данные битые" и тд и тп.
и вот в таком случае, если меняется модель ответа, ты меняешь код только маппинга, а бизнес логика, UI логика остается такой же, как и раньше.