Dependency Inversion - главный инструмент Архитектора
Вставка
- Опубліковано 12 вер 2024
- Что такое Dependency Inversion
Примеры реализации
Почему, ты обязан понимать DI
Подписывайтесь на мой telegram канал:
t.me/cleanfron...
Моя библиотека Tiny Invert:
www.npmjs.com/...
Курсы:
Redux - micro-courses....
FSD - micro-courses....
00:00:26 - Что такое DI
00:03:20 - Пример реализации DI
00:10:35 - Зачем нужен DI
00:16:52 - Почему ты должен понимать DI
00:22:09 - Типичные примеры использования DI
00:27:50 - Ты даже не знал, что это DI
Предлагаю сделать серию видосов каждый сеньор должен знать. Отличный контент
Поддерживаю!
Ну прям булочка, такой радостный и довольный сидит 🙂
сделай tutorial по Tiny Invert. очень надо
@paromovevg вы б хотя б продемонстрировали как использовать вашу либу с реактом. или это будет следующее видео?
лучший
Спасибо за классный обзор DI ! Либо я все сильно упрощаю, либо все реально сильно проще, но как по мне DI - разработка на уровне интерфейсов, а не конкретных реализаций. Получается мы просто создаем интерфейс который компонент А будет использовать, а потом уже любой другой компонент Б должен реализовать этот интерфейс.
данное видео идеально показывает то, что 'компоненты' в реакте не очень то и похожи на компоненты, а являются обычными функциями, которые возвращают значение
Так можно было бы сказать, если бы понятие "компонент" не было задано самими авторами React
Авторы React назвали функцию которая возвращает React.Element компонентом, и всё. То что это просто функция, никто не отменяет
@@paromovevg это вводит в заблуждение разработчиков не только из других сфер, но даже тех же фронтендеров, которые до этого с реактом не работали, можно было использовать такое понятие, как template
в видео же показано решение проблемы 'компонентов' в реакте, поскольку в других инструментах это решается гораздо легче, но конечно, само по себе видео хорошо объясняет принцип)
@@danilka6295 То что я не особо думал о людях которые не знают React -- правда моя ошибка. Признаю
@@paromovevg🎉
Спасибо, Женя. Только одна просьба, на экране редактора кода масштабируй текст плиз. Раза в 3-4. место же позволяет?
Огонь. Быстро и понятно... А... Я на 1.5 скорости послушал... Но всё равно понятно. Такое бы видео полтора года назад, чтобы я мог объяснить коллегам по работе, чем их компонента была плоха
Браво! Отличное объяснение
Эта библиотека - типа аналог @Autowired в java?
SPA на реакте тот еще глобус с совами)
Поймал себя на мысли, что на примерах разбивки компонентов можно объяснять и single responsobility, и Coupling/Cohesion и наверное еще много все умного
По факту React компонент это функция.
Что и SRP применим к функциям, и вообще все принципы программирования я думаю, никто не спорит
Хотелось бы чуть больше инфы про недостатки применения dependency inversion
Коммент в поддержку
Tiny Invert это же по сути реализация inversion of control container? Слой для связывания абстрактных интерфейсов с их реализациями и доступа к ним
По факту да, упрощает связывание абстракций с реализациями
Его можно и к inversion of control притянуть, но такой концептуальной мысли я в него не закладывал
Нужен пример использования до/после и тд
Все сеньоры в сборе?!
Спасибо за разбор темы. А в чём отличие от dependency injection?
Dependency injection - это инструмент, который позволяет удобно делать dependency inversion
Мой tiny invert по факту замена dependency injection
🔄 Зависимость от конкретных реализаций усложняет код и препятствует его повторному использованию.
⬆ Инверсия зависимостей - это инструмент, позволяющий абстрагироваться от реализации и управлять потоками зависимостей.
🔗 Инверсия зависимостей заключается в том, что абстрактный класс зависит от интерфейсов, а конкретные классы реализуют эти интерфейсы.
🛠 Инверсия зависимостей используется для улучшения тестируемости, расширяемости и гибкости кода.
💪 Архитектор должен уметь применять инверсию зависимостей для проектирования надежных и гибких систем.
При всем желании не могу понять, каким это образом у нас меняется так называемое направление зависимостей. В чём концептуальная разница между кейсами, где наш компонент что-то заимпортил и где он взял это что-то пропсами? Ну да, у нас более универсальный модуль, да мы зависим не от конкретного пропса, а от n-ого пропса, имеющего определённый интерфейс. А где тут стрелочка то поворачивается?
Самая гравная разница, кто является держателем типа. Раньше компонент B теперь компонент А
Теперь компонент А меняется только при изменении своих собственных типов
Лайкосиков этому господину!
Интересно, как компонент А зависит от В? А если из А в B будут проброшены пропсы?
Сам факт импорта уже зависимость. Компонент B может быть переименован перенесен, поменять интерфейс или логику. Все приведет к изменениям A
К примеру, если пропсы изменяться в компоненте B, то A надо рефакторить
покажешь как это реализовать на vue nuxt? )))
Там беда
Но почти всегда спасают слоты с параметрами, те же рендер пропсы
@@paromovevg покажешь расскажешь?)))
Первый ❤
умничка, есть повод для гордости
@@kitsunaana9783 ага, стал лучше понимать dependency inversion
16:54 Мне же не послышалось? 😂
какой ты умничка. заметил, что человек оговорился
молодец
Оказывается это так просто, а то некоторые типы так загоняют.. походу сами не понимат))