Я всё ещё не понимаю, зачем придумывать специальные названия для здравого смысла? Приходишь на собеседование, а тебе там "а что такое тындрение залысенностей?". сиди и думай блин. потом окажется, что это паттерн разделения своей ноги и направления выстрела
Мне тоже это не нравится. Сильно усложняет понимание. Однако, это терминология, проф язык. В общении между программистами в команде, вместо использования длинных формулировок с уточнениями, проще назвать термин и всем сразу становится понятно о чем речь. Хотя порой программисты увлекаются, и придумывают новые термины там, где это не нужно, наверно для самоутверждения.
@@voidplusplusru Всё равно выпендрёж. Никогда не слышал на работе высокоинтеллектуальных бесед на тему паттернов и таких вот терминов при обсуждении кода. Даже если паттернов в коде навалом, то его всё равно могут не понимать. Может паттернов не знают? Но на собеседовании видимо это важно.
@@alexanderbelov6892 поддерживаю, обычно у тебя задача и ты идешь и пишешь ее решение без всяких указаний что и как. Обычно такие вопросы проводят неопытные специалисты- или только с института или hr. Горазда важнее посмотреть как именно будет решаться задача, а не определение терминов
Вот так надо Внедрение зависимости (англ. Dependency injection, DI) - процесс предоставления внешней зависимости программному компоненту. Является специфичной формой «инверсии управления» (англ. Inversion of control, IoC), когда она применяется к управлению зависимостями. В полном соответствии с принципом единственной ответственности объект отдаёт заботу о построении требуемых ему зависимостей внешнему, специально предназначенному для этого общему механизму[1].
Есть достаточно удачная формулировка: "класс должен зависеть от абстракции, а не от конкретной реализации", и далее можно рассказать про агрегацию в виде передачи параметра типа интерфейса в конструктор класса и что этот подход является эволюцией фабричного метода 🙂
Только что узнал о существовании этой фичи и вроде, как круто, не нужно создавать экземпляры классов. Нооо не понимаю, как это применить с MVVM, биндинги отлично отделяют вьюшку от viewmodel и делают их не зависимыми друг от друга, как я понял эта фича помогает сделатт viewmodel более независимой от самой model. Но тогда, как мне свойства вьюмодели привязать к данным, я же не могу в классе вьюмодели делать sql запросы, напрямую привязывать тоже, в конструкторе вьюмодел, я не могу передавать аргументы, возникнет ошибка между вьюшкой и самой вьюмоделью, наследовать я тоже не могу, ведь вьюмодел уже наследуется от BindableBase да и смысла нету реализовывать это во вьюмодел, ведь суть и заключается, чтобы отделить ее от модели. Допустим есть данные в sql и модель этих данных, я создам интерфейс и класс который будет вытаскивать данные из БД, а теперь как свойства вьюмодел привязать к этим данным? Не совсем понимаю что такое Response в примере, просто класс который реализует этот интерфейс? Извиняюсь если задаю глупые вопросы, не так давно начал изучать паттерны очень сложно самому находить понятную простым смертным информацию(. Пукан подгорел пока пытался найти что-то по MVVM и внедрению зависимостей, какие-то контейнеры, какие-то хостинги, службы, сервисы...
Не уверен, что полностью понял, что вы пытаетесь сделать. Полагаю, что в вашем случае нужно внедрять зависимость (некий сервис, который вытаскивает данные из БД) во вьюмодел. Тут есть пример community.devexpress.com/blogs/wpf/archive/2022/02/07/dependency-injection-in-a-wpf-mvvm-application.aspx В моем примере Response - это просто модель, которую возвращает метод, отношения к DI не имеет.
Остался вопрос по контейнеру. Должна быть возможность зарегистрированные зависимости локализовать, верно? Потому что не везде мне нужно подставлять так, как я хочу в конкретном месте. В одном месте я такую зависимость регистрирую, в другом - другую, и они друг другу противоречат... Например, вот здесь 4:37 меня устраивает связь DbContext. А вот в другом месте я хочу MyDbContext
Это можно решить разными способами. Зависит от того, что позволяет делать конкретный IoC. В некоторых случаях можно именовать каждую регистрацию. Я бы в таком случае просто сделал интерфейс IMyDbContext, который наследует от IDbContext и MyDbContext будет его реализовывать. И там, где нужен MyDbContext указываем интерфейс IMyDbContext.
Стремление получить звучное название привело к путанице с этим методом. Здесь нет внедрения, здесь явное устранение зависимости от реализации путем замены типа контракта с класса на интерфейс. Место создания передаваемого объекта вообще не имеет отношения к рассматриваемому методу. Суть его не будет нарушена, если вместо IDbContext будет передана фабрика контекстов, а сам контекст будет создан через вызов ее метода.
Я не знаю зачем мне Ютуб выплюнул это видео, видимо чтобы я оставил тебе коммент =) Я часто сталкиваюсь с тем, что у собеседников переплетено понятие внедрения зависимостей и инверсии зависимостей (хотя в целом, с точки зрения реализации без контейнера выглядит одинаково и их тут нечего судить), ну и даже если программист понимает теорию внедрения, то не может ответить в чем же его минусы, а ведь о них написано не так много и обычно понимаешь только набив пару шишек. В общем, я бы добавил такую инфу в видео, чтобы получилось поставить точку над i. Удачи!)
На данный момент, это лучшее объяснение DI, которое я встречал!
Почему ты не снимаешь другие видео по программированию. С таким объяснением и примерами тебе цены нет💪
госпади, здоровье тебе и твоим родственникам, это просто самое божественное, краткое и емкое объяснение DI.
2 года прошло, а до сих пор лучшее объяснение, советую всем нашим джунам)
Это лучшее, что мог найти, простыми словами, порт для устройства. Круто Спасибо! Побольше б таких видео.
Почему застрял? Давай новые ролики. Голос отличный. Ролик лаконичный. Требую продолжения банкета!
самый лаконичный и доходчиво ответ. браво!
Я всё ещё не понимаю, зачем придумывать специальные названия для здравого смысла? Приходишь на собеседование, а тебе там "а что такое тындрение залысенностей?". сиди и думай блин. потом окажется, что это паттерн разделения своей ноги и направления выстрела
Мне тоже это не нравится. Сильно усложняет понимание. Однако, это терминология, проф язык. В общении между программистами в команде, вместо использования длинных формулировок с уточнениями, проще назвать термин и всем сразу становится понятно о чем речь. Хотя порой программисты увлекаются, и придумывают новые термины там, где это не нужно, наверно для самоутверждения.
@@voidplusplusru Всё равно выпендрёж. Никогда не слышал на работе высокоинтеллектуальных бесед на тему паттернов и таких вот терминов при обсуждении кода. Даже если паттернов в коде навалом, то его всё равно могут не понимать. Может паттернов не знают?
Но на собеседовании видимо это важно.
@@alexanderbelov6892 поддерживаю, обычно у тебя задача и ты идешь и пишешь ее решение без всяких указаний что и как. Обычно такие вопросы проводят неопытные специалисты- или только с института или hr. Горазда важнее посмотреть как именно будет решаться задача, а не определение терминов
Разделение ноги, направление выстрела...
В этом нет смысла или я тупой.
@@vladbreez4036 одно другому не мешает, хоть я и правда немного коряво сформулировал
Очень хорошо объяснено. Давай в догонку IoC и так по всем основным понятиям.
😯 Моё лицо когда посмотрел видео про DI, а понял что такое moq и для чего он по сути нужен))))
Очень круто, сколько юзал данный подход, но не знал что
То и есть di
Офигеть, принцип инверсии зависимостей и композицию выделили аж в отдельный паттерн 😂
Это просто гениальное объяснение!!! Спасибо 🙏👏👏👏👏
Как раз готовлюсь к собеседованиям. Ролик очень полезен. Спасибо!
Ролик бомба! Спасибо за разъяснение.
вельми дякую) дуже лаконічне поясненя
хмм, не знаю почему, быть может просто настало время, но именно на этом ролике я начал более менее понимать, зачем нужен этот паттерн проектирования
Вот так надо
Внедрение зависимости (англ. Dependency injection, DI) - процесс предоставления внешней зависимости программному компоненту. Является специфичной формой «инверсии управления» (англ. Inversion of control, IoC), когда она применяется к управлению зависимостями. В полном соответствии с принципом единственной ответственности объект отдаёт заботу о построении требуемых ему зависимостей внешнему, специально предназначенному для этого общему механизму[1].
Идеально! столько болтовни вокруг этой херни, а туту хрясь пара скринов и все сразу ясно)) Для Java это тоже подходит
кратко и понятно везде бы так
Есть достаточно удачная формулировка: "класс должен зависеть от абстракции, а не от конкретной реализации", и далее можно рассказать про агрегацию в виде передачи параметра типа интерфейса в конструктор класса и что этот подход является эволюцией фабричного метода 🙂
@@mamikonpapikyan6120 , Ioc - идея, dependency inversion - принцип, dependency injection - реализация
@@apdgslfhsodbna Вы путаете два понятия близкие к себе но всё же разные.
Я обычно прошу написать функцию сложения двух чисел без DI
классное объяснение
Ещё один положительный момент а ДИ это возможность поумничать перед кандидатом😂
Запили такой же видосик по IoC и IoC-контейнерам, ради христа)
Спасибо за разъяснения
Только что узнал о существовании этой фичи и вроде, как круто, не нужно создавать экземпляры классов. Нооо не понимаю, как это применить с MVVM, биндинги отлично отделяют вьюшку от viewmodel и делают их не зависимыми друг от друга, как я понял эта фича помогает сделатт viewmodel более независимой от самой model. Но тогда, как мне свойства вьюмодели привязать к данным, я же не могу в классе вьюмодели делать sql запросы, напрямую привязывать тоже, в конструкторе вьюмодел, я не могу передавать аргументы, возникнет ошибка между вьюшкой и самой вьюмоделью, наследовать я тоже не могу, ведь вьюмодел уже наследуется от BindableBase да и смысла нету реализовывать это во вьюмодел, ведь суть и заключается, чтобы отделить ее от модели. Допустим есть данные в sql и модель этих данных, я создам интерфейс и класс который будет вытаскивать данные из БД, а теперь как свойства вьюмодел привязать к этим данным? Не совсем понимаю что такое Response в примере, просто класс который реализует этот интерфейс? Извиняюсь если задаю глупые вопросы, не так давно начал изучать паттерны очень сложно самому находить понятную простым смертным информацию(.
Пукан подгорел пока пытался найти что-то по MVVM и внедрению зависимостей, какие-то контейнеры, какие-то хостинги, службы, сервисы...
Не уверен, что полностью понял, что вы пытаетесь сделать. Полагаю, что в вашем случае нужно внедрять зависимость (некий сервис, который вытаскивает данные из БД) во вьюмодел. Тут есть пример community.devexpress.com/blogs/wpf/archive/2022/02/07/dependency-injection-in-a-wpf-mvvm-application.aspx
В моем примере Response - это просто модель, которую возвращает метод, отношения к DI не имеет.
@@voidplusplusru то что я искал, спасибо огромное !
Интересно, а если мне нужно передать объект, который имплементируется неск интерфейсами?..
D в SOLID - это Dependensy Inversion. А вы назвали и объяснили dependency injection. Темы немного пересекающиеся, но всё таки разные
👀👀👀👀
Где SOLID автором упомянут?
спасибо за видео!
Остался вопрос по контейнеру. Должна быть возможность зарегистрированные зависимости локализовать, верно? Потому что не везде мне нужно подставлять так, как я хочу в конкретном месте. В одном месте я такую зависимость регистрирую, в другом - другую, и они друг другу противоречат...
Например, вот здесь 4:37 меня устраивает связь DbContext. А вот в другом месте я хочу MyDbContext
Это можно решить разными способами. Зависит от того, что позволяет делать конкретный IoC. В некоторых случаях можно именовать каждую регистрацию. Я бы в таком случае просто сделал интерфейс IMyDbContext, который наследует от IDbContext и MyDbContext будет его реализовывать. И там, где нужен MyDbContext указываем интерфейс IMyDbContext.
хрена себе комменты, видимо, тут все и так в курсе, как это работает, т.к. если бы я был не в курсе - хер бы что было понятно....
Годно, спасибо
Стремление получить звучное название привело к путанице с этим методом. Здесь нет внедрения, здесь явное устранение зависимости от реализации путем замены типа контракта с класса на интерфейс.
Место создания передаваемого объекта вообще не имеет отношения к рассматриваемому методу. Суть его не будет нарушена, если вместо IDbContext будет передана фабрика контекстов, а сам контекст будет создан через вызов ее метода.
Вы случайно не играли в бдо ? Очень похожий голос просто
Хорошо изложен материал, жду новые видео 😀
а я так ваще ниче не понял)))
Я не знаю зачем мне Ютуб выплюнул это видео, видимо чтобы я оставил тебе коммент =)
Я часто сталкиваюсь с тем, что у собеседников переплетено понятие внедрения зависимостей и инверсии зависимостей (хотя в целом, с точки зрения реализации без контейнера выглядит одинаково и их тут нечего судить), ну и даже если программист понимает теорию внедрения, то не может ответить в чем же его минусы, а ведь о них написано не так много и обычно понимаешь только набив пару шишек. В общем, я бы добавил такую инфу в видео, чтобы получилось поставить точку над i.
Удачи!)
В чем же его минусы?
Почав з залежностей, закінчив інверсією тих же залежностей( не сказавши про це), потім на di контейнер переліз)))) ляяяяя жесть
Спасибо!
Вначале я не понял, а потом я начал тупо угорать 😂 Потом дежавю
Di - это агрегация, так?
Чел харош
За 4 минуты вся база, а то зае... своими книгами по 400+ страниц с кучей воды, на такие простые темы не очень как по мне важные
чел, угорает, МНОГО РАЗЖЕВАННОЙ информация
Нихуя не понял, ладно
Тема размазана в ограниченных знаниях автора… читай больше, ServiceLocator не обходи.