СОДЕРЖАНИЕ: 00:00:00 - введение и немного обо мне ;) 00:02:33 - диаграмма Use Case (диаграмма Вариантов использования) 00:16:07 - пример в коде на Java 00:19:01 - основы Clean architecture Android (чистая архитектура)
Не один день интернет переворачивают в поисках, вот именно такого объяснения, где все визуализировано и это же показано на коде. Божественная подача. Такого бы спеца в менторы себе. Спасибо огромное. Улетел смотреть далее... 👍
очень-очень круто, спасибо большое. пришёл на этот канал в попытке понять тот...материал, который купил у практикума. сам ментор дал ссылку со словами, что у вас хорошо объяснено. спасибо большое, мне очень зашло
Добрый вечер, Тимофей! Пожалуйста, развивайте дальше Ваши гайды по Clean, да и вообще в целом. Подача информации просто на высоте! Все просто и понятно, так держать!
Спасибо огромное за видео! В рабочем проекте использовались эти самые юз кейсы и я никак не мог понять, в чем их принципиальная суть, теперь все стало понятно)
Как абстрагированный пример с Use Case всё супер круто и понятно изложено, спасибо большое) Но как быть с данными, которые нужны этому useCase? Например ему нужна какая-то сущность из бд. В каком виде её передавать в useCase? Как данные возвращать? В каком виде? Как это дело правильно мапить? Как domain слою общаться с presentation и model? Как реализовывать правило зависимостей на практике? В общем довольно много вопросов по clean'у)) Тянет на полноценный курс лекций. Идеальным вариантом было бы конечно на практике от А до Я разобрать проект и как его правильно строить по clean. Жду продолжения:) Спасибо автору за работу, очень прикольное изложение материала!
В следующих видео это все будет :). А если в краце, то никто не запрещает в конструктор UseCase что то передать, например интерфейс за которым прячется реализация работы с базой или нетворком.
Спасибо, полезно. 1. Тема про то зачем нужны отдельные классы для юзкейсов не раскрыта, неужели все дело в инкапсуляции? Я могу и функцию создать приватную с одним "юзкейсом". 2. А вот что особенно мне понравилось это наглядная привязка юзкейсов на диаграмме к UI-приложению, так действительно удобно проектировать функционал
1. Дело в SOLID. А точнее в принципе единой ответсвенности. Один класс одна ответственность, если делать много паблик методов, вероятнее всего это приведет к нарушению данного принципа.
Попытаюсь раскрыть за автора. Тут дело не столько в SOLID. Если коротко: классы нужны, чтобы сделать "частичное применение функции" (забиндить аргументы) Юзкейсы - это фактически обычные функции, и могут быть ими заменены (потому что у usecase всегда один метод, и usecase всегда stateless). Но у юзкейсов есть зависимости, которые нужно инжектить. Если бы юзкейсы были бы функциями, то нам пришлось бы поставлять зависимости прямо в месте вызова - и так делать было бы очень не удобно. Если бы у нас был JS, то мы бы сделали просто bind аргументов. Но Java/Kotlin так сделать нельзя (точнее геморно). Поэтому юзкейсы просто сделали классами. DI-фреймворк создает их и автоматически инжектит нужные зависимости, а мы уже вызываем его где нам нужно, не думая о зависимостях ничего. Если бы DI умели бы прозрачно инжектить прямо в функции, то думаю юзкейсы были бы функциями, а не классами.
@@TimofeyKovalenko если следовать такому подходу, то придется каждую функцию выносить в отдельный класс, что странно и неудобно, и вряд ли кто-то так делает S-принцип, он скорее про разделение ответственности относительно пользователей (Вы когда нибудь делали приложение у которого несколько типов пользователей? Там понимание принципа становится однозначным. Это больше похоже на разделение интерфейсов, только с другой стороны, т.е. получается разделение реализации) В общем наличие в классе нескольких функций не обязательно нарушает этот принцип
Спасибо за работу, очень доходчиво. Хотелось бы уточнить, проектируя архитектуру приложения мы всегда ориентируемся на взамодействие с пользоателем, как в данном видео (use case) или есть еще варианты?
Use Case не обязательно решает проблему пользователя, это может быть какае-то внутренняя функциональность. Просто мобилка в большинсве случаев это клиентское приложение, поэтому вся бизнес логика это как правило решение так или иначе проблем пользователя.
Добрый день, очень клевый ролик с доступным объяснением, почему не объясняете сразу на Котлин а на джаве? еще вопрос, для построения приложения мы используем либо clean либо например MVVM или мы и то и то используем в одном приложении? И еще вопрос, когда откроется набор на курсы?
Интересно конечно, что это за класс с одной "функцией", который реализует логин в твиттер. С учетом что любая oauth2 требует сторону redirect и callback endpoint.
Я согласен с тем что необходимо рисовать диаграммы, но хотелось бы получить полную информацию о том как это делать, какие правила построения и оформления этих диаграмм, а не просто поиметь посыл - "делайте так, но это черновик". Не согласен с расположением UseCase в Domain области, так как это уже не чистая архитектура, а DDD (Domain Driven Design) чистая архитектура. Этот вариант расположения предусматривает создание бизнес правил внутри домена, но вносит тем самым путаницу с взаимосвязями - при использовании Clean Architecture + DDD проект становится подвержен неправильному направлению связей классов, его становится сложнее поддерживать, так как необходимо все время контролировать вручную верно ли располагаются связи, или же мы допускаем ошибку. Рефакторить приходится чаще, обслуживание проекта становится дороже. Clean Architecture предполагает же наоборот уровень ядра (Core) в который входит Domain и Application, а внутри Application находятся UseCase. Это гарантирует правильное строение взаимосвязей классов, благодаря которому проект становится проще обслуживать.
Спасибо вам, очень полезная информация. Среди комментариев я видел вопрос по поводу использования use case'ов в виде singleton. Ответ понятен. А какое ваше мнение по поводу использования в виде интерфейсов? Т.е. имеет ли смысл так делать и писать имплементации юзкейсов? Бывают ли ситуации в реальных проектах, чтобы поиходилось менять имплементацию и не затрагивать другую логику? А также тестируются ли юзкейсы? Например, через DI инжектить имплементацию и её менять на тестовую для тестирования?
На мой взгляд делать с интерфейсами особого смысла нет, очень наврят ли у вас будет несколько имплементаций, а если и будет, можно сделать только в необходимых местах. Юз кейсы покрываются тестами обязательно, но DI тут не нужен. Вообще старайтесь не затаскивать в тесты лишнее, просто берите объект юз кейса и тестите, если нужно протестить класс, где используется юз кейс, делайте мок на основе класса юз кейса и все.
Тимофей, к сожалению, не нашёл ссылки на первоисточники о чистой архитектуре и юзкейсах в этой серии видео. Не могли бы вы перечислить их? Книги, неапример, или известные статьи...
Если вы имеете ввиду те жуткие диаграммы с кругами от автора клин архитектуры, но даже не буду давать на них ссылки, в адекватном состоянии их не понять)))). Источников много, в первую очередь читайте не о клин архитектуре, а о SOLID и паттернах
Есть много классов UseCase, в каждом из которых есть один публичный метод execute. А нет ли здесь нарушения принципа DRY? Эти методы execute обладают самой разнообразной сигнатурой. Поэтому спрятать их за общим интерфейсом-прародителем interface UseCase { fun execute() } - затруднительно
Вы можете сделать параметризированный базовый класс с входящим и исходящим параметром. DRY тут не нарушается, каждый UseCase - это отдельная логика, в чем тут проблема? Повторяется название метода, это не проблема. Можете не execute назвать, это не важно. Это просто устоявшееся название, а не строгое правило
Не знаю увидите или нет мой комментарий стало интересно! Урок у вас отличный, но появился вопрос: вы сказали что clean architecture это когда один класс выполняет одну функцию, но разве это в целом не относится к принципу SOLID а конкретно к Single Responisibility?
Сам по себе, клин - это немного другое, это описание структуры и взаимодействия разных частей приложения, то есть более глобальная штука. И естественно при реализации клин мы используем различные паттерны и в том числе следуем принципам SOLID. Одно другое дополняет ;)
Как всегда, проблема упрощенных примеров - они не отображают суть реальных кейсов) В данном случае юзкейс GetMovieImagesByPage выполняет функцию RecyclerViewAapter'а или просто поставляет ему готовый ArrayList для загрузки? Какую роль тогда выполняет адаптер - он является частью бизнес логики или принадлежит к какой-то другой части архитектуры?)) Не поймите неправильно, видео классное, но вопросов стало больше, чем было до просмотра)
Здравствуйте, расскажите какая логика в useCase. Если я получил список из интернета и хочу сделать по нажатию кнопки сортировку или поиск, локально на устройстве не отправляя запрос в сеть. Надо писать логику в useCase или в viewModel? Надо писать в useCase только логику которая связана с data слоем?
Невозможно ответить, вариантов может быть много, в зависимости от количества данных, приложения и многих других факторов. Приходите на курс, расскажем ;))
А если из Репозитория передавать результат запроса в сеть, то нужно под результат запроса тоже создавать отдельный UseCase или можно в том же UseCase? При том что успешно полученные данные не получаются через результат запроса в методе из репозитория , т.к. данные получаются из базы данных, в которую репозиторий их запишет.
Не совсем понял вас. У вас есть UseCase у которого есть метод с входящими и исходящими(return) данными. Зачем вам отдельный UseCase для возврата данных?
@@TimofeyKovalenko Да. В одном usecase 2 функции, одна - обращается в репозиторий для запроса в сеть, а другая - передает во ViewModel результат запроса в сеть, если произошла ошибка. Это неправильный подход?
@@funnymoment9164 напишите пожалуйста пример кода такого UseCase, я тогда подробнее поясню вам на его основе, а то мне кажется вы фундаментально запутались в том как должен выглядеть UseCase.
@@funnymoment9164 Так: 1) Использовать LiveData в UseCase крайне не желательно, так как это все же андроидовская штука, а UseCase не должен иметь ничего общего с платформенными фичами. 2) UseCase должен содержать только один публичный метод. 3) Можно ведь вот так сделать: class GetCurrentWeatherFromNetworkUseCase @Inject constructor( private val repository: IRepositoryCurrentWeather ) { suspend fun getCurrentWeather(): ResultWrapper { return repository.getCurrentWeather() } } А еще лучше назвать метод: suspend fun execute(): ResultWrapper {} ну либо suspend fun get(): ResultWrapper {}. Так как весь смысл того, что делает данный метод уже есть в названии класса.
Вопрос, если UseCase класс по сути функциональный, то не правильно ли было бы их делать синглтонами, дабы не было возможности оперировать классами юзкейсов как сущностями?
1) Синглтонами в целом лучше не злоупотреблять 2) Реальной пользы от того, что Use Case станет синглтоном, нет никакой, Use Case не хранит никакого состояния, которое необходимо делить между разными клиентами (если у вас хранит, значит с этим Use Case что-то не так) 3) Если Use Case будет синглтоном, значит он будет всегда висеть в памяти, даже тогда когда он уже не нужен, а юз кейсов может быть очень много в приложении 4) С UseCase синглтоном потенциально могут быть проблемы, например один клиент поиспользовал логику юз кейса и оставил там артефакты (какие-то данные, состояние и тд), соответсвенно все это достанется другому клиенту, хотя и не должно 5) Ну и сама суть юз кейса в том, что он обслуживает конкретного клиента, а не всех подряд. Да, оперируем ими как сушностями, но не вижу в этом никаких проблем, синглон намного больше проблем добавит.
Да, 50 классов. Но если у вас действительно, есть такая "супер активити", то тут вопрос к тому, точно ли приложение сделано правильно, может не нужно на одной активити столько функционала? ;)
Что значит другие юз кейсы? Если вам нужен один и тот же юз кейс в нескольких активити, то переиспользуете его, юз кейсы же не привязаны к активити, они живут своей жизнью).
При всем уважении, отличный материал, но автору нужно поработать над краткостью речи :-) По 2-3 минуты объяснять, то почему он не будет объяснять тот или иной аспект, ну такое...
Знаете, намного чаще приятнее слушать тех, кто всё разжевывает, чем тех, кто скачет с вопроса на вопрос. Ведь лучше 3 минуты послушать одно и то же, чем потом 30 пытаться понять, что же имел в виду автор
Посмотрел первое видео. Если в таком духе и дальше объяснения, то лет так через десять новичкам -можно- нужно будет все это выкинуть и начинать смотреть нормальные курсы. Так и появляется индусский стиль программирования - с неверно выбранного курса. ДА выглядит просто, НО по факту - лажа. GetMovieByPage))
Даже для простейшего приложения с 2мя экранами на диаграмме с десяток "яиц", а теперь представь, что будет с приложением чуть посложнее? Основной косяк данного повествования - это совершенно не раскрыт момент многоуровневости диаграмм! Есть закон восприятия информации, по которому должно быть не более 7, в очень крайнем случае 10 элементов в любом списке. Поэтому сначала рисуется диаграмма верхнего уровня, при клике по кейсам которой проваливаешься в кейсы нижнего уровня. В данном примере для логина 1 кейс, для регистрации 1 кейс и при клике по ним уже показываются всякие логины через пейсбуки и пр. И не рисуй стрелки ИЗ актора! Стрелка начинается рядом с ним. А то аналитик какой-нибудь увидит и сдохнет от смеха. Жалко их все-таки, тоже ведь человеки :)))
СОДЕРЖАНИЕ:
00:00:00 - введение и немного обо мне ;)
00:02:33 - диаграмма Use Case (диаграмма Вариантов использования)
00:16:07 - пример в коде на Java
00:19:01 - основы Clean architecture Android (чистая архитектура)
Не один день интернет переворачивают в поисках, вот именно такого объяснения, где все визуализировано и это же показано на коде. Божественная подача. Такого бы спеца в менторы себе. Спасибо огромное. Улетел смотреть далее... 👍
Спасибо что есть такие уроки, объясняющие казалось бы базовые вещи простым языком.
очень-очень круто, спасибо большое. пришёл на этот канал в попытке понять тот...материал, который купил у практикума. сам ментор дал ссылку со словами, что у вас хорошо объяснено. спасибо большое, мне очень зашло
Спасибо за уроки, талант преподавать и объяснять тему
Добрый вечер, Тимофей! Пожалуйста, развивайте дальше Ваши гайды по Clean, да и вообще в целом. Подача информации просто на высоте! Все просто и понятно, так держать!
Божественная подача, все очень доходчиво, благодарю, одно лишь замечание, не забрасывай пожалуйста канал=)
Тимофей, спасибо за видео! Для меня, как начинающего специалиста, прекрасно изложен материал :)
Спасибо огромное за видео! В рабочем проекте использовались эти самые юз кейсы и я никак не мог понять, в чем их принципиальная суть, теперь все стало понятно)
Хорошо объясняете, понятно и без лишних слов. Спасибо!
Спасибо! И правда, видео очень полезное и проясняющее как логичнее подходить к разработке. Очень захотелось почитать книгу по чистой архитектуре.
Очень крутой урок. Очень полезная информация! Лайк и подписка. Спасибо учитель.
Случайно наткнулась на ваше видео, очень понравилось как вы просто и понятно объясняете, лайк и подписка! Спасибо вам за видео =)
Это просто шикарное видео, решил подтянуть теорию и не прогадал с выбором, спасибо!
Спасибо!
Слушать и учиться - одно удовольствие!
😀
Тимофей, большое спасибо за урок!!!
Спасибо автору, очень просто и полезно объяснил. Понял все с первого раза!
Полезное видео, спасибо. Особенное спасибо за использование диаграммы :)
Как абстрагированный пример с Use Case всё супер круто и понятно изложено, спасибо большое) Но как быть с данными, которые нужны этому useCase? Например ему нужна какая-то сущность из бд. В каком виде её передавать в useCase? Как данные возвращать? В каком виде? Как это дело правильно мапить? Как domain слою общаться с presentation и model? Как реализовывать правило зависимостей на практике? В общем довольно много вопросов по clean'у)) Тянет на полноценный курс лекций. Идеальным вариантом было бы конечно на практике от А до Я разобрать проект и как его правильно строить по clean. Жду продолжения:) Спасибо автору за работу, очень прикольное изложение материала!
В следующих видео это все будет :). А если в краце, то никто не запрещает в конструктор UseCase что то передать, например интерфейс за которым прячется реализация работы с базой или нетворком.
Спасибо Тимофей. Уроки очень полезны и интересны )))
Я вам очень благодарна, Тимофей!Лайк!С новым годом вас!
Очень круто! Наконец то начал понимать Клин)
😉
Хороший комментарий, спасибо!
Ну да, когда пишешь класс думаешь эгоистично .. типа ну мне-то понятно почему в нём столько функций ) постепенно переучиваешься
Спасибо за релевантную информацию...было интересно плюс хорошая подача продолжай!!
Спасибо за труды!
Спасибо, очень классная лекция
Отличное видео и очень комфортно слушать.
спасибо большое, прям вот то что нужно, отличная подача материала)
😉
Спасибо за видео! Всё очень понятно.
Спасибо за труды)) очень полезно!
То чувство, когда учишь язык 3 месяца, а потом выясняется, что надо было с архитектуры начинать) Спасибо, было полезно, пошел все переделывать!)
Вообще-то наоборот, архитектура намного сложнее, ну да ладно
@@tpov_oleg она-то сложнее, я не спорю. Но без неё все равно нормального кода не напишешь.
@@ДенисСухоруков-е2о А со знаниями архитектуры, но без нормальных знаний языка, вообще ничего не напишешь)
Очень круто! Огромное спасибо!
Тимофей, спасибо!!
Очень полезно! Даже сказал бы сверхполезно) спасиб
Очень полезное видео!Спасибо!
Огромное спасибо за ролик!)
Правда год 2021, а классы почему-то на Java ))
Спасибо, полезно.
1. Тема про то зачем нужны отдельные классы для юзкейсов не раскрыта, неужели все дело в инкапсуляции?
Я могу и функцию создать приватную с одним "юзкейсом".
2. А вот что особенно мне понравилось это наглядная привязка юзкейсов на диаграмме к UI-приложению, так действительно удобно проектировать функционал
1. Дело в SOLID. А точнее в принципе единой ответсвенности. Один класс одна ответственность, если делать много паблик методов, вероятнее всего это приведет к нарушению данного принципа.
Попытаюсь раскрыть за автора. Тут дело не столько в SOLID.
Если коротко: классы нужны, чтобы сделать "частичное применение функции" (забиндить аргументы)
Юзкейсы - это фактически обычные функции, и могут быть ими заменены (потому что у usecase всегда один метод, и usecase всегда stateless). Но у юзкейсов есть зависимости, которые нужно инжектить. Если бы юзкейсы были бы функциями, то нам пришлось бы поставлять зависимости прямо в месте вызова - и так делать было бы очень не удобно. Если бы у нас был JS, то мы бы сделали просто bind аргументов. Но Java/Kotlin так сделать нельзя (точнее геморно).
Поэтому юзкейсы просто сделали классами. DI-фреймворк создает их и автоматически инжектит нужные зависимости, а мы уже вызываем его где нам нужно, не думая о зависимостях ничего.
Если бы DI умели бы прозрачно инжектить прямо в функции, то думаю юзкейсы были бы функциями, а не классами.
@@TimofeyKovalenko если следовать такому подходу, то придется каждую функцию выносить в отдельный класс, что странно и неудобно, и вряд ли кто-то так делает
S-принцип, он скорее про разделение ответственности относительно пользователей
(Вы когда нибудь делали приложение у которого несколько типов пользователей? Там понимание принципа становится однозначным. Это больше похоже на разделение интерфейсов, только с другой стороны, т.е. получается разделение реализации)
В общем наличие в классе нескольких функций не обязательно нарушает этот принцип
@@juneuniversum тоже к этому пришел, благодарю за подробный ответ :)
Спасибо за видео, много чего нового узнал для себя : )
спасибо! ваши видео очень интересно смотреть.
😉
Спасибо за видео.Коммент в поддержку!
Спасибо)
Это было очень полезно. Ваш контент оставляет только один вопрос: почему на канале так мало подписчиков???
Очень здорово, большое спасибо
Спасибо, очень понятное объяснение
Для меня очень интересно было!!!
Спасибо
Было очень полезно, красава! Яху
Спасибо за видео, это было очень полезно)
Спасибо большое! Помогло.
Спасибо за работу, очень доходчиво. Хотелось бы уточнить, проектируя архитектуру приложения мы всегда ориентируемся на взамодействие с пользоателем, как в данном видео (use case) или есть еще варианты?
Use Case не обязательно решает проблему пользователя, это может быть какае-то внутренняя функциональность. Просто мобилка в большинсве случаев это клиентское приложение, поэтому вся бизнес логика это как правило решение так или иначе проблем пользователя.
Весьма доступно! Еще видео будет?
Конечно будут), просто на дворе лето... отпуска... поэтому немного реже выходят чем в зимний сезон.
Большое спасибо! Очень полезно!
Суперски, спасибо
Спасибо, очень полезно и понятно.
Здравствуйте. Урок по автогенерации кода из модели есть?
Добрый день, очень клевый ролик с доступным объяснением, почему не объясняете сразу на Котлин а на джаве? еще вопрос, для построения приложения мы используем либо clean либо например MVVM или мы и то и то используем в одном приложении? И еще вопрос, когда откроется набор на курсы?
Посмотрите все остальные ролики, там есть ответы на все эти вопросы ;)
Было очень полезно, спасибо. Только можно, пожалуйста, на котлине)
Дальше все видео на Koltin ).
Интересно конечно, что это за класс с одной "функцией", который реализует логин в твиттер. С учетом что любая oauth2 требует сторону redirect и callback endpoint.
Спасибо за видео для меня было очень полезно
Спасибо 👍🏻🔥
Большое спасибо
эх, выходил бы этот цикл видео, когда я писал диплом... Было бы сто крат легче со всем разбираться
Я согласен с тем что необходимо рисовать диаграммы, но хотелось бы получить полную информацию о том как это делать, какие правила построения и оформления этих диаграмм, а не просто поиметь посыл - "делайте так, но это черновик".
Не согласен с расположением UseCase в Domain области, так как это уже не чистая архитектура, а DDD (Domain Driven Design) чистая архитектура.
Этот вариант расположения предусматривает создание бизнес правил внутри домена, но вносит тем самым путаницу с взаимосвязями - при использовании Clean Architecture + DDD проект становится подвержен неправильному направлению связей классов, его становится сложнее поддерживать, так как необходимо все время контролировать вручную верно ли располагаются связи, или же мы допускаем ошибку. Рефакторить приходится чаще, обслуживание проекта становится дороже.
Clean Architecture предполагает же наоборот уровень ядра (Core) в который входит Domain и Application, а внутри Application находятся UseCase.
Это гарантирует правильное строение взаимосвязей классов, благодаря которому проект становится проще обслуживать.
Спасибо вам, очень полезная информация.
Среди комментариев я видел вопрос по поводу использования use case'ов в виде singleton. Ответ понятен. А какое ваше мнение по поводу использования в виде интерфейсов? Т.е. имеет ли смысл так делать и писать имплементации юзкейсов? Бывают ли ситуации в реальных проектах, чтобы поиходилось менять имплементацию и не затрагивать другую логику? А также тестируются ли юзкейсы? Например, через DI инжектить имплементацию и её менять на тестовую для тестирования?
На мой взгляд делать с интерфейсами особого смысла нет, очень наврят ли у вас будет несколько имплементаций, а если и будет, можно сделать только в необходимых местах. Юз кейсы покрываются тестами обязательно, но DI тут не нужен. Вообще старайтесь не затаскивать в тесты лишнее, просто берите объект юз кейса и тестите, если нужно протестить класс, где используется юз кейс, делайте мок на основе класса юз кейса и все.
Тимофей, к сожалению, не нашёл ссылки на первоисточники о чистой архитектуре и юзкейсах в этой серии видео. Не могли бы вы перечислить их? Книги, неапример, или известные статьи...
Если вы имеете ввиду те жуткие диаграммы с кругами от автора клин архитектуры, но даже не буду давать на них ссылки, в адекватном состоянии их не понять)))).
Источников много, в первую очередь читайте не о клин архитектуре, а о SOLID и паттернах
Есть много классов UseCase, в каждом из которых есть один публичный метод execute. А нет ли здесь нарушения принципа DRY?
Эти методы execute обладают самой разнообразной сигнатурой. Поэтому спрятать их за общим интерфейсом-прародителем interface UseCase { fun execute() } - затруднительно
Вы можете сделать параметризированный базовый класс с входящим и исходящим параметром. DRY тут не нарушается, каждый UseCase - это отдельная логика, в чем тут проблема? Повторяется название метода, это не проблема. Можете не execute назвать, это не важно. Это просто устоявшееся название, а не строгое правило
Очень полезно, на мой взгляд материал изложен достаточно подробно. Спасибо!
Спасибо!!!
Не знаю увидите или нет мой комментарий стало интересно! Урок у вас отличный, но появился вопрос: вы сказали что clean architecture это когда один класс выполняет одну функцию, но разве это в целом не относится к принципу SOLID а конкретно к Single Responisibility?
Сам по себе, клин - это немного другое, это описание структуры и взаимодействия разных частей приложения, то есть более глобальная штука. И естественно при реализации клин мы используем различные паттерны и в том числе следуем принципам SOLID.
Одно другое дополняет ;)
Как всегда, проблема упрощенных примеров - они не отображают суть реальных кейсов) В данном случае юзкейс GetMovieImagesByPage выполняет функцию RecyclerViewAapter'а или просто поставляет ему готовый ArrayList для загрузки? Какую роль тогда выполняет адаптер - он является частью бизнес логики или принадлежит к какой-то другой части архитектуры?)) Не поймите неправильно, видео классное, но вопросов стало больше, чем было до просмотра)
Это опен-сорс проект в видео? Может кто-то скинуть ссылку на Гитхаб проекта?
Большое спасибо!
незачно ;)
а можно ли наследовать usecase если хочешь избежать дублирования кода. Ну или композировать
Я не очень люблю использовать наследование для шаринга общего функционала, лучше вынесете общие части в отдельный класс
Очень полезно!!!
Здравствуйте, расскажите какая логика в useCase.
Если я получил список из интернета и хочу сделать по нажатию кнопки сортировку или поиск, локально на устройстве не отправляя запрос в сеть. Надо писать логику в useCase или в viewModel?
Надо писать в useCase только логику которая связана с data слоем?
Невозможно ответить, вариантов может быть много, в зависимости от количества данных, приложения и многих других факторов. Приходите на курс, расскажем ;))
А если из Репозитория передавать результат запроса в сеть, то нужно под результат запроса тоже создавать отдельный UseCase или можно в том же UseCase? При том что успешно полученные данные не получаются через результат запроса в методе из репозитория , т.к. данные получаются из базы данных, в которую репозиторий их запишет.
Не совсем понял вас. У вас есть UseCase у которого есть метод с входящими и исходящими(return) данными. Зачем вам отдельный UseCase для возврата данных?
@@TimofeyKovalenko Да. В одном usecase 2 функции, одна - обращается в репозиторий для запроса в сеть, а другая - передает во ViewModel результат запроса в сеть, если произошла ошибка. Это неправильный подход?
@@funnymoment9164 напишите пожалуйста пример кода такого UseCase, я тогда подробнее поясню вам на его основе,
а то мне кажется вы фундаментально запутались в том как должен выглядеть UseCase.
@@TimofeyKovalenko
class GetCurrentWeatherFromNetworkUseCase
@Inject constructor(
private val repository: IRepositoryCurrentWeather
) {
var getNetworkResponseResult: LiveData =
repository.networkResponseResult
suspend fun getCurrentWeather() {
repository.getCurrentWeather()
}
}
@@funnymoment9164 Так:
1) Использовать LiveData в UseCase крайне не желательно, так как это все же андроидовская штука, а UseCase не должен иметь ничего общего с платформенными фичами.
2) UseCase должен содержать только один публичный метод.
3) Можно ведь вот так сделать:
class GetCurrentWeatherFromNetworkUseCase
@Inject constructor(
private val repository: IRepositoryCurrentWeather
) {
suspend fun getCurrentWeather(): ResultWrapper {
return repository.getCurrentWeather()
}
}
А еще лучше назвать метод:
suspend fun execute(): ResultWrapper {} ну либо suspend fun get(): ResultWrapper {}. Так как весь смысл того, что делает данный метод уже есть в названии класса.
Вопрос, если UseCase класс по сути функциональный, то не правильно ли было бы их делать синглтонами, дабы не было возможности оперировать классами юзкейсов как сущностями?
1) Синглтонами в целом лучше не злоупотреблять
2) Реальной пользы от того, что Use Case станет синглтоном, нет никакой, Use Case не хранит никакого состояния, которое необходимо делить между разными клиентами (если у вас хранит, значит с этим Use Case что-то не так)
3) Если Use Case будет синглтоном, значит он будет всегда висеть в памяти, даже тогда когда он уже не нужен, а юз кейсов может быть очень много в приложении
4) С UseCase синглтоном потенциально могут быть проблемы, например один клиент поиспользовал логику юз кейса и оставил там артефакты (какие-то данные, состояние и тд), соответсвенно все это достанется другому клиенту, хотя и не должно
5) Ну и сама суть юз кейса в том, что он обслуживает конкретного клиента, а не всех подряд. Да, оперируем ими как сушностями, но не вижу в этом никаких проблем, синглон намного больше проблем добавит.
Ничего не понял, что за юзкейс. То есть, если у меня в активити есть 50 функций, и чтобы сделать чистую архитектуру нужно 50 этих классов юзкейс?
Да, 50 классов. Но если у вас действительно, есть такая "супер активити", то тут вопрос к тому, точно ли приложение сделано правильно, может не нужно на одной активити столько функционала? ;)
@@TimofeyKovalenko да, 36 в активити на 1200 строк и 10 в вьюмодель. Так а для других активити нужно другие юзкейсы?
Что значит другие юз кейсы? Если вам нужен один и тот же юз кейс в нескольких активити, то переиспользуете его, юз кейсы же не привязаны к активити, они живут своей жизнью).
При всем уважении, отличный материал, но автору нужно поработать над краткостью речи :-) По 2-3 минуты объяснять, то почему он не будет объяснять тот или иной аспект, ну такое...
Знаете, намного чаще приятнее слушать тех, кто всё разжевывает, чем тех, кто скачет с вопроса на вопрос. Ведь лучше 3 минуты послушать одно и то же, чем потом 30 пытаться понять, что же имел в виду автор
Ссылку на приложение не нашёл, оно open source ?
p.s. нашёл но комменты со ссылками удаляют, не смогу поделится
ссылки на приложение не давал, пишите сами по примеру из видео, иначе толку не будет ;)
@@TimofeyKovalenko я про приложение movie
Кстати там не разделено всё по папкам на domain data, трудно ориентироваться
Да, это просто пример, который был взять из github. Использовал его просто, что-бы визуально функционал показать.
Посмотрел первое видео. Если в таком духе и дальше объяснения, то лет так через десять новичкам -можно- нужно будет все это выкинуть и начинать смотреть нормальные курсы. Так и появляется индусский стиль программирования - с неверно выбранного курса. ДА выглядит просто, НО по факту - лажа. GetMovieByPage))
Предложите свой вариант и расскажите подробнее почему вы считаете, это не правильным. С удовольствием поболтаю)
Даже для простейшего приложения с 2мя экранами на диаграмме с десяток "яиц", а теперь представь, что будет с приложением чуть посложнее? Основной косяк данного повествования - это совершенно не раскрыт момент многоуровневости диаграмм! Есть закон восприятия информации, по которому должно быть не более 7, в очень крайнем случае 10 элементов в любом списке. Поэтому сначала рисуется диаграмма верхнего уровня, при клике по кейсам которой проваливаешься в кейсы нижнего уровня. В данном примере для логина 1 кейс, для регистрации 1 кейс и при клике по ним уже показываются всякие логины через пейсбуки и пр. И не рисуй стрелки ИЗ актора! Стрелка начинается рядом с ним. А то аналитик какой-нибудь увидит и сдохнет от смеха. Жалко их все-таки, тоже ведь человеки :)))
Вот только видео я делаю не для аналитиков или профессоров UML)))
трата времени
Очень полезно!!!
Спасибо большое
Спасибо
Огромное спасибо.
Спасибо!
спасибо
Спасибо
Спасибо!