Осенью 2024-го сразу три курсанта в один день (!) упомянули всуе DI, а потом вскоре и в отзывах пришло на эту тему:

"Тестирование FE - пока есть ощущение, что код я пишу без DI и прочих подходов, которые облегчат интеграционное тестирование с подкинутыми фейковыми зависямостями. С другой стороны я слабо понимаю, а как тестируется визуальное представление веб-компонента :)"

"Начала выстраиваться наконец-то модель ООП,которая изначально выстроена,к сожалению,с помощью Dependency Injection - как и везде сейчас,и слабого курса в универе,где мы просто С++ учили."

"Оказывается, я открыл F-ограниченный полиморфизм в тот момент, когда мне понадобилось, чтобы методы класса-родителя явно (на уровне статического анализа) возвращали и принимали аргументы конкретных типов, являющихся производными класса-потомка. Даже получилось реализовать это в Python, в котором изначально типы не считались такими уж важными. Это инверсия зависимостей на математических стероидах. "

"Я только вот 1 не понял,в конце вы написали про DI в современных приложениях,и это правда очень искажает понимание ООП,но вы написали,что оно увеличивает coupling из-за того,что мы открываем все наши зависимости. А концепт ADT,где мы описываем типы данных только операциями как раз является решением,потому что вся реализация полностью скрыта и лежит на классе реализующим ADT. Но разве с этими DI контейнерами не так? Определили интерфейс,реализовали его классом в который уже внедряются зависимости,и класс как раз скрывает всю реализацию."

Подробно разбираю эту тему в свежем материале для курсантов: 108-й СИ "Не путаем DI и ADT", даю в частности 10 случаев, когда лучше избегать Dependency Injection в рамках ADT, + 10 ключевых причин, почему это качественно разные вещи, и соответственно как это всё правильно готовить.