Например наш сервер ждет http запрос. Если инверсии контроля нет, то нам придется буквально ждать и постоянно проверять не пришел ли он (например бесконечным while/setInterval). С инверсией контроля мы эту задачу отдаем модулю http, просто навешивая обработчик события (коллбэк). По крайней мере я так понял, посмотрев видео и прочитав пару статей на хабре. Знающие, поправьте, если я не прав

Представьте ситуацию когда у вас есть файл в котором лежит класс, но в этом файле нет ни одного импорта, а все зависимости в класс передаеются через конструктор класса - а потом все зависимости передаются в класс где он создается. Зачем это нужно это очень интересный вопрос, который меня так же мучал очень долгое время, и по моим скромным размышлениям это не очень то часто и нужно в бизнес логике проекта, но все же есть несколько условных юзкейсов, где это может быть полезно, которые я попытаюсь описать: 1. Представьте что у вас большой проект и над ним работают, пусть будет, три команды A, B, C и ваш архитектор хочет распаралелить их работу, что быстрее запилить фичу для клиента, но есть проблема - команда А пилит модуль от которого зависит команда В, а вот команда С тоже зависит от модуля А но и модуля С. Назревает очевидная проблема, что распаралелить работу не получиться, потому что сначала нужно дождаться пока команда А сделает свой модуль, потом В и потом уже С - это будет очень долго и тут приходит на помощь depedency inversion(DI)/iversion of control(IoC) - вы просто договариватесь перед старом работы про интерфейсы которые будут предоставлены модулями от команды A, B и C и начинаете работу, написав какие то примитивные моки, которые бы соотвествовли оговоренным контрактам/интерфейсам. А по мере готовности настоящих модулей - просто подменяете свои моки на настоящий рабочий код от ваших команд. 2. Есть теоретическая необходимость подменять зависимости внешние зависимости (библиотечки). Например вы пилите приложение которое выдает пользователю очень удобную статистику по погоде. И у вас есть сторонний сервис к которому вы обращаетесь за информацией и вы можете его юзать напрямую в коде и не парится, а потом вам приходит письмо от босса, где говорится, что сервис закрывается или что он подымает цену и вам надо перейти на другой сервис, и вам предоставляют новый. И тут перед вами встает задачка пробежаться по всему коду и вручную выпиливать старую либу и заменять на новую. Как раз в такой ситуации IoC мог бы быть полезным. Написав свой сервис обертку над библиотекой погоды, который имеет определенный интерфейс и возвращает удобные для вас данны, вы его передаете как зависимость в другие модули (через конструктор если класс, или как аргументы функции) и уже ваша бизнес логика использует вашу абстракцию и если надо поменять либу вы просто меняте свой код в одном месте и все в теории может работать так же. И вам не будут страшны ситуации теперь когда вам могут прийти снова и попросить поменять библиотеку на новую или вернуться к старой. Но есть огромное НО, вышеописаные ситуации встречаются редко и даже если вы работаете в большой компании то в условиях украинского рынка чаще всего это будет небольшие или среднего размера проекты с аутсорса, а даже если и будете несколькими командами работать над одним проектом - очень редко случается ситуации когда фичи пилятся параллельно (разве что только при старте проекта, что тоже бывает очень редко). А кейс с необходимостью подмена внешних библиотек так же крайне редок - программисты на практике редко меняют библиотеки баз данных, логеров и прочее, как правило все они это железобетонные решения, а если даже и надо будет это сделать (подменить старую либу на нову) то может оказаться что "наивный" способ когда ходим по каждому файлу и правим ручками гораздо быстрее и дешевле в глобальном контекте, чем постоянно тратить силы и время на поддержку кодовой инфрастктуры в IoC стиле. Но все же, почему же IoC может быть полезен? Если начать разбираться, то на первый взгляд может показаться, что это просто бесполезная игрушка для заскучавших программистов по временам когда они играли конструкторы лего (или им подобные). НО, IoC может быть крайне полезен для написанию юнит тестов. Представьте ситуацию что вы хотите протестировать ваш код в котором есть логирование в базу данных или в файловую систему, получается при каждой прогонке тестов, ваше хранилище будет заполнятся мусором, но если вы написали ваш код используя подход Dependency Inversion то во время тестов вы просто и легко можете замокать все модули которые являются лишними или вредными для тестирования. Но снова есть НО, это полезно для экосистем типа java, c#, go, kotlin, а если же вы прогоняете тесты в экосистемах типа python, ruby, nodejs - вы можете мокать любые модули и зависимости, даже глобальные объекты без особого труда и таким образом отпадает необходимость упарываться в DI/IoC за отсуствием какого либо профита. Резюмируя вышесказаноое, IoC это не серебрянная пуля и не однозначное добро, как утверждает автор канала и этот подход не должен использоваться всеми и вся. Более того, любой код - это потенциальное место для ошибок и всегда требует вермени и сил для поддержки (в том чиле и код который пишется для работы IoC) и как вы подметили, можно писать код в два раза быстрее без DI/IoC, поэтому каждый разработчик сам, или команда должны определять нужно ли реализовывать этот подход в проекте или нет. Надеюсь объяснил доступно и понятно.

@@ievgenk.8991 Более или менее, конечно живой проект был бы краше, но и то хлеб. Спасибо. Надо бы еще своего лида этим вопрос напрячь😂

@@ievgenk.8991 хорошо объяснил, по сути для тестов нужно, остальное все крайне маловероятное да

@@ievgenk.8991 ваш коммент это самое полезное, что я нашла в русскоязычном интернете ❤

Да, я тоже так понял. И любое приложение - это некий плагин для операционной системы, кстати.

Ты перепутал DIP и IoC.

@@user-hc1hl2nx8e спасибо за замечание

Только, как правило, мы его уже не пишем сами, а используем уже написанный

Зачем себя так принижать!

@@user-bz8ip1zo5d это шутка :)