Comments 19
Цитата про «5-центовую концепцию» задела за живое — не могу с ней согласиться. У этой идеи есть свои корни и непростой путь реализации.
Подмена реализаций для тестов и продакшена действительно упрощается. Но если копнуть глубже, мы упираемся в те же три столпа ООП — инкапсуляцию, наследование и полиморфизм. Проще говоря, мы просто переносим часть «магии» и повторяющегося кода внутрь IoC-контейнера.
IoC — полезный, но нетривиальный концепт: он снимает с нас много рутины, но заставляет глубже понимать архитектуру. В простых проектах вполне можно обойтись ручным DI — это проще и быстрее. Но как только логика усложняется или появляются циклические зависимости, ручная обвязка превращается в ад.
Не хотелось бы, чтобы разработчики чрезмерно упрощали концепцию и приходили к неправильному пониманию.
Претензий к статье нет, но цитата Джеймса Шора зацепила :)
Спасибо за статью — было интересно прочитать.
IoC не имеет отношения к DI, держу в курсе.
Просто ради интереса, а чем являются dig и wire?
Ну быстрое гугление говорит, что это DI библиотеки для Go. При чем тут это?
В предыдущем комментарии я ошибся в терминологии: под «IoC» я имел в виду IoC-контейнер. Возможно, из-за этого мой посыл был не до конца понятен.
dig и wire - это реализации IoC-контейнеров, которые реализуют паттерн Dependency Injection.
Конечно, можно сказать, что dig и wire - просто библиотеки, и это тоже будет правдой, но важно понимать, какой паттерн стоит за ними и глубину мысли.
Спора нет, просто хотел убедиться, что мы говорим об одном и том же.
Как по мне такое должно называться DI-контейнеры (так в большинстве случаев и называют). IoC это вообще про другое, это про инверсию контроля/управления. Вот когда вы в каком-нибудь любимом веб-фреймворке добавляете хэндлеры для обработки HTTP запросов, добавляете какие-нибудь middleware и потом фреймворк это вызывает, вот это и называется IoC, т.е. поток управления инвертирован, не вы вызываете, а вас вызывают.
Подписка на события не имеет отношения к IoC/IoC-контейнерам - это просто асинхронная парадигма программирования. Она встречается как в популярных веб-фреймворках, так и на уровне ОС: без неё невозможно обеспечить интерактивность и отзывчивость системы. Кажется, вы смешиваете разные вещи.
IoC-паттерн же касается другого: наш код зависит не от конкретной реализации, а от абстракции (интерфейса), а конкретная реализация «внедряется» извне. Здесь как раз задействуется полиморфизм.
Вы вправе называть это DI-контейнером - ваше право, - но терминология паттернов нужна для сжатой и однозначной передачи мысли собеседнику и общего понятийного аппарата.
Непонимаю, какие вы тут события нашли... Вообщем можете открыть статью на англ/русской википедии про IoC, там неплохо написано про то, чем это является.
IoC-паттерн же касается другого: наш код зависит не от конкретной реализации, а от абстракции (интерфейса)
Вы не правы. IoC может быть вообще без интерфейсов. Он про то, что не программист управляет потоком выполнения, а фреймворк.
Если уж пытаться дружить эти термины, DI это очень частный случай IoC. Поэтому DI-контейнер более точный термин.
Такая однозначная, что сколько лет она существует, столько лет ее и понимает каждый по своему
Все вы правильно пишите, di - одна из возможных реализации inversion of control (ioc)
Как-то в go эти DI выглядят ущербно.
я плохо представляю как можно без DI сделать гибкий фреймворк и делать на нем приложения. хотя представляю, форкаем и правим :) вообще полно разных странных людей, кто-то до сих пор утверждает что типы не нужны, ну и ради бога, пускай каждый делает как хочет и набивает свои шишки, некоторые даже испытывают удовольствие от этого
DI так то не только к ооп применяется. Внезапно, func getUser(id int, db *Db) это тоже DI. Просто не нужно писать на джаве в го так как в джаве нет способа объявить функцию без класса.
Вот тут можно посмотреть еще один интересный подход без классического контейнера, правда на питоне https://fastapi.tiangolo.com/tutorial/dependencies/#create-a-dependency-or-dependable
Вероятно, вам не нужен DI-фреймворк