Неплохое видео, но осталось какое-то количество вопросов после просмотра. 1. сомнительное утверждение что надо показывать всё что ты знаешь и умеешь. Разве суть задачи не в том, чтобы решить ее максимально оптимальным способом? 2. По поводу разделения слоёв, разве переименование файлов как и работа с файловой системой в целом можно 100% отнести к бизнес логике? 3. если говорить про платформонезависимый код, то очень странно говорить что вполне нормально использовать R класс в таком коде. Да он автогенерируемый и это просто набор интов, но почему он должен быть вообще? А FileRenamer так и продолжает его использовать. 4. Продолжение п.2 но с сущностями Resource, почему используются Int значения в качестве идентификатора ресурса? Откуда уверенность в том, что айди будет именно интом? 5. Самый главный вопрос, почему решение 2 в данном случае хуже чем решение 3? У нас и там, и там есть какой-то класс для предоставление строки из ресурсов. В обоих случаях нам надо писать платформозависимый код для получение ресурсов из конкретной платформа, только в решении 2 это минус, а в решении 3 мы не говорим что это минус. 6. Почему мы говорим что решение 3 более гибкое за счёт того, что мы добавили переменную с ресурсом в сигнатуру метода? В данном конкретном случае у нас не просто переименование файла, т.е. мы не просто меняем имя файла на значение из ресурсов. У нас идёт добавление префикса и это выглядит как более специфическая и узкая задача. Нужна ли нам эта псевдогибкость с параметром префикса вообще? 7. Ну и как уже писали под оригинальным заливом и тут тоже, куда лучше и гибче использовать какие-то константы(енамы, что угодно) и маппер на ресурсы уже непосредственно в UI классе, чтобы что-то рисовать на UI. Как по мне решение 2 сильно лучше чем решение 3 с точки зрения KISS.
Повторюсь еще раз. Зачем все эти доп провайдеры и прочее в бизнес логике? Не правильней было бы: на бизнес слое оперировать модельками бизнес слоя, а в ui уже мапить в строки и прочее, таким образом бизнес логика ничего не знает и не должна знать о строках на ui.
Если речь про то чтобы достать строку, чтобы потом отобразить ее на ui, то соглашусь, использование провайдеров для получения строки из ресурса в бизнес логике - зачастую лишнее. Тем более что если делать это неправильно, то при смене языка на телефоне, текст на экране не сменится. Однако если текст будет использоваться, не для отображения UI, а для каких-либо дальнейших вычислениях, то я не вижу другого выхода. Тот же пример из видео. Как взять новое название файла без констант и провайдеров? Работа с файлами это явно не то, что хочется делать на UI слое.
Так же задаюсь вопросом По идее бизнес логика выбросит id ресурса. На этом цель закончилась. Отображение ресурса уже как то на обязанность ui больше подходит
@@hievery9678Только вот тогда вопрос - почему в файловом менеджере идёт логика о получении имени файла? Уже нарушение single responsibility. С таким успехом в этот класс, который служит для работы с файлами, можно засунуть VR камеру, плеер, и игру в крестики нолики.
Не понятно почему вариант с вынесением получения платформозависимого кода из вне вообще не рассматривался. Хотелось бы узнать причину. В видео не раскрыто почему аннотации Res не являются чисто андроидовскими: они есть и на других платформах тоже?
эх, столько абстракций, надеюсь, когда-нибудь до меня дойдет зачем это всё и как до этого додумываться самому, а сейчас я бы наверное просто заюзал вариант с константой и прокидыванием строки в параметр функции, а выше уже где-то думал как ее туда засунуть
Абстракции - это не страшно и на большом масштабе кода и команды позволяет строить масштабиремый софт и тестировать его. Оптимизиатор кода R8 потом уберет все лишние прослойки и эффект на код будет минимален. Создавать объекты тоже нестрашно - виртуальная машина ART уже давно нацелена на то что постоянно создается много обёектов
🔗 Платная подписка на Boosty abdev.by/oroS и в Telegram abdev.by/lrpW
🔗 Telegram Android Broadcast t.me/+y-LPEB3R5-9mNmRi
✉ Написать Кириллу kirill@androidbroadcast.dev
Неплохое видео, но осталось какое-то количество вопросов после просмотра.
1. сомнительное утверждение что надо показывать всё что ты знаешь и умеешь. Разве суть задачи не в том, чтобы решить ее максимально оптимальным способом?
2. По поводу разделения слоёв, разве переименование файлов как и работа с файловой системой в целом можно 100% отнести к бизнес логике?
3. если говорить про платформонезависимый код, то очень странно говорить что вполне нормально использовать R класс в таком коде. Да он автогенерируемый и это просто набор интов, но почему он должен быть вообще? А FileRenamer так и продолжает его использовать.
4. Продолжение п.2 но с сущностями Resource, почему используются Int значения в качестве идентификатора ресурса? Откуда уверенность в том, что айди будет именно интом?
5. Самый главный вопрос, почему решение 2 в данном случае хуже чем решение 3? У нас и там, и там есть какой-то класс для предоставление строки из ресурсов. В обоих случаях нам надо писать платформозависимый код для получение ресурсов из конкретной платформа, только в решении 2 это минус, а в решении 3 мы не говорим что это минус.
6. Почему мы говорим что решение 3 более гибкое за счёт того, что мы добавили переменную с ресурсом в сигнатуру метода? В данном конкретном случае у нас не просто переименование файла, т.е. мы не просто меняем имя файла на значение из ресурсов. У нас идёт добавление префикса и это выглядит как более специфическая и узкая задача. Нужна ли нам эта псевдогибкость с параметром префикса вообще?
7. Ну и как уже писали под оригинальным заливом и тут тоже, куда лучше и гибче использовать какие-то константы(енамы, что угодно) и маппер на ресурсы уже непосредственно в UI классе, чтобы что-то рисовать на UI.
Как по мне решение 2 сильно лучше чем решение 3 с точки зрения KISS.
Повторюсь еще раз. Зачем все эти доп провайдеры и прочее в бизнес логике? Не правильней было бы: на бизнес слое оперировать модельками бизнес слоя, а в ui уже мапить в строки и прочее, таким образом бизнес логика ничего не знает и не должна знать о строках на ui.
Если речь про то чтобы достать строку, чтобы потом отобразить ее на ui, то соглашусь, использование провайдеров для получения строки из ресурса в бизнес логике - зачастую лишнее. Тем более что если делать это неправильно, то при смене языка на телефоне, текст на экране не сменится.
Однако если текст будет использоваться, не для отображения UI, а для каких-либо дальнейших вычислениях, то я не вижу другого выхода. Тот же пример из видео. Как взять новое название файла без констант и провайдеров? Работа с файлами это явно не то, что хочется делать на UI слое.
Так же задаюсь вопросом
По идее бизнес логика выбросит id ресурса. На этом цель закончилась.
Отображение ресурса уже как то на обязанность ui больше подходит
@@hievery9678Только вот тогда вопрос - почему в файловом менеджере идёт логика о получении имени файла? Уже нарушение single responsibility. С таким успехом в этот класс, который служит для работы с файлами, можно засунуть VR камеру, плеер, и игру в крестики нолики.
Не понятно почему вариант с вынесением получения платформозависимого кода из вне вообще не рассматривался. Хотелось бы узнать причину.
В видео не раскрыто почему аннотации Res не являются чисто андроидовскими: они есть и на других платформах тоже?
Весь пакет androidx.annotations уже давно KMP
а что за клавиатура? Видео тоже крутое)
Вчера на ночь посмотрел, что-то на эту тему снилось. Еще раз смотреть?
Перезалив вынужденный был, а может и знак
Ну, для запоминания как раз лучше вечером перед сном и утром после сна
эх, столько абстракций, надеюсь, когда-нибудь до меня дойдет зачем это всё и как до этого додумываться самому, а сейчас я бы наверное просто заюзал вариант с константой и прокидыванием строки в параметр функции, а выше уже где-то думал как ее туда засунуть
Абстракции - это не страшно и на большом масштабе кода и команды позволяет строить масштабиремый софт и тестировать его. Оптимизиатор кода R8 потом уберет все лишние прослойки и эффект на код будет минимален. Создавать объекты тоже нестрашно - виртуальная машина ART уже давно нацелена на то что постоянно создается много обёектов
А что делать, если для условных Prefereces для самого их создания нужен контекст? Это же по идее data слой, но туда обычно не хотят контекст закинуть
Туда обычно же application context как раз и закидывают )
Хорошая прическа, можно налысо и нарисовать черным маркером :)
На junior такие есть вопросы?
Вполне могут быть
Избавляемся от контекста - по сути делаем обертку для контекста. Мда
перезалив?
Да, перезалив вынужденный
А что случилось с первым?
Удален