🧩 SOLID: DIP - Принцип инверсии зависимостей - Dependency inversion principle для JavaScript
HTML-код
- Опубликовано: 10 фев 2025
- 👉 Примеры кода: github.com/How...
👉 Курс по асинхронному программированию: github.com/How...
👉 Курс по Node.js: github.com/How...
👉 Автор: github.com/tsh...
👉 Другие материалы: github.com/How...
Спасибо!
Дождался!
Спасибо за видео , в теории знаю - но по факту не применяю, анализируя свой код , если это не предусмотрено фреймворками = значит-таки не понимаю принципы
Спасибо за материал!
Тимур, в каком приложении вы рисуете эти блок-схемы - зелёные на чёрном фоне? Выглядят потрясающе.
Google slides
Было бы здорово, в данном видео увидель разбор примера кода, как правильно реализовать этот паттерн. А то как неправльно, есть код, а как правильно нет кода.
@@DimitarRad так в курсе по паттернам есть по каждому принципу разбор примеров кода, а код в репозитории, ссылка под этим видео, там есть и пример с нарушением и правильный
Добрый день Тимур!)
Вопрос, возможно, глупый, но тем не менее:
- А везде ли и всегда ли нужно следовать данному принципу?
Я столько говнокодил, что любая тема рассказанная вами для меня выглядит, как идеальный подход для решения любых задач (прям как в анекдоте про молоток в руках).
Вот и хочется выяснить насколько широка область применения, да когда можно или даже нужно отступать от данного принципа ))
Принципы SOLID и GRASP не просто не нужно применять везде, но и невозможно, они даже могут противоречить и мешать друг другу. Где что применять это регулируется размером проекта, его жизненным циклом, как быстро нужно сделать прототип, как быстро нужно ввести в эксплуатацию, ожидается ли поток изменений и какой интенсивности он будет, какая команда работает над проектом, есть ли текучка кадров и как передается культура кода, сколько времени кодавая база будет поддерживаться, это может быть одноразовый код или проект, который проживет 20 лет, нужно его передавать от команды разработки команде эксплуатации, в какой сфере проект и будет ли аудит безопасности или сертификация, какой у нас бюджет, ограниченные средства или можно развернуться по полной и ещё можно 5 страниц мелким текстом перечислять, что и для чего применяется, но в принятии таких решений неизбежны ошибки, это нормально, просто их уровень не должен быть очень велик, много зависит от интуиции архитектора, главного инженера и лидов проекта, от баланса интересов стейкхолдеров, от доступных для найма кадров, и ещё многих факторов.
@TimurShemsedinov получается нет единого правильного подхода для создания того или иного сервиса. И вся его начинка (имею ввиду архитектуру и взаимодействие внутренних частей кода) будет сильно зависеть от внешних факторов, а не только от планируемого функционала.
Если это так, то вы мне немного осветили тьму.
Большое спасибо за ответ и уделённое мне время!)
Можете дать совет, как набираться опыта и насмотпенности тому, кто большую часть времени работает один?
@yomo1abh586 вот работать одному это очень малоэффективно в плане развития, лучше даже плохенький, но коллектив))) присоединяйтесь к комьюнити, к оупенсорсу, с друзьями делайте стартап, самое главное, чтоб вы регулярно делали и получали ревью кода, чтоб обсуждали структуру и архитектуру, не замыкались в себе, а находили общее мнение
@@TimurShemsedinov страшно, что говницо мое кто-то разнюхивать будет ))
Вообще работаю один из-за ситуации в республике, где разработчиков либо нет, либо они свинтили за рубеж.
По итогу я буквально один в компании, кто занимается веб разработкой (full stack).
Фронт уже я писал, а вот часть бека - php написанный то ли 12, то ли 14 лет назад )))
Мало по малу пристраиваю node к этому делу.
За совет спасибо, буду стараться вливаться в общество.
К слову, сегодня в первые побывал на созвоне с вами, пока пытался вопрос озвучить, чуть инфаркт не хватил ))
Слишком много переживаний, когда сталкиваешься с тем, кто для тебя является примером для подражания))
Спасибо за внимание. Хорошего вам вечера, Тимур.
DIP - это плоть от плоти функционального программирования, которую потом стали распространять на прочие концепции.
Достаточно посмотреть на лямбда исчисление, чтобы увидеть там тот самый DIP. При этом сама концепция лямбд появились задолго до машини тьюринга.
тихо, тихо ;)
лямбди та автомати йшли "ніздря в ніздрю".
Лямбда-числення
Алонзо Черч, "An Unsolvable Problem of Elementary Number Theory" (1936).
Кінцеві автомати Тюрінга
Алан Тюрінг, "On Computable Numbers, with an Application to the Entscheidungsproblem" (1936-1937).
то ж ... я б не сказав, що прям аж "задовго" ;)
О, разработческие упанишады продолжаются, значит мир ещё жив.
здраствуйте тимур, подскажите ваш курс введения в js стоит смотреть человеку который толком не кодил?
Есть для совсем начинающих, вот этот ruclips.net/video/HetL0ETbN6Y/видео.html а есть большой курс github.com/HowProgrammingWorks/Index/blob/master/Courses/Fundamentals.md
9:10 - але краще так не робити. Тимур на початку відео каже, що нам треба мати можливість перенести застосунок в інше середовище, наприклад на мобілку, то як раз від всіх особливостей системи краще обстрагуватися.
І насрпавді, існує інший підхід, коли інтерфейсний шар просто імпортує бізнес-логіку -- це цілком дозволено DIP-ом, а у випадку з JS та TS є звичним підходом до структури застосунку.
12:20 - а от і ні! ;) Service Locator порушує DIP, бо компонент (клас) починає залежити від сервіс-локатору, який є абстракцією найнижчого рівня. Саме тому, всі DI рішення, що тягнуть декоратори в класи -- порушують DIP