Здравствуйте,

S>>> M>>Просто кейс что при использовании DI в конструктор передали null невозможен в принципе, тут нужен другой пример.
S>>> IT>Пусть передали не null, а поломаный объект.
S>>> Передали, и? Чем поведение без DI будет отличаться от поведения с DI в данном случае?
S>·>Я не очень понял твой вопрос, но попробую потелепатить. Различие в том, что в случае с обычным кодом, можно найти откуда конкретно передали просто проанализировав код, find usages. В случае DI-фреймворка ты можешь лишь понять, что пришло из контейнера и всё, и без дебаггера очень сложно разобраться.

S>Согласен, это я и имел ввиду. Т.е. разница во времени поиска причины, а не в поведении кода, его реакции, на поломанный объект.
S>За гибкость разработки приходится платить, увы. Серебряной пули нету.

как сказать

с одной стороны, если мы говорим о поломанных объектах, то при правильном программировании инвариантов их возможное существование будет пресекаться на корню. либо в конструкторе, либо в фабрике/билдере. и это безотносительно DI, а просто как правило хорошего тона и clean code.

с другой стороны, если мы перспективу иметь отсечение невалидных объектов (а инварианты могут быть существенно сложнее, чем просто not-null какого-то аргумента) будем рассматривать в контексте инстанцирования синглтонов в рамках какого-то фреймворка DI, то затраты технически будут равны тем, что возникнут и без DI. и там, и там нужно запустить процесс и увидеть, падает он или нет, а на этапе компилирования даже при поддержке некоторых аннотаций, абсолютно все проблемы подобного типа отловить не удастся.

к чему это я (ответ всем тем, кто отметился в этой подветке): не надо сравнивать DI или не-DI там, где проблемы возникают по другим причинам.

и ещё одно небольшое дополнение:
— анализ стек-трейсов причин, почему контейнер DI во время запуска упал из-за нарушения инвариантов синглтонов, даётся легко, если соответствующие исключения снабжены говорящими уникальными текстами, явно указывающими на суть нарушения.
— пользоваться дебаггером для этого — моветон. нужно учиться логировать и читать логи. в первую очередь из-за того, что, когда проблема прилетает из продуктива, никакой дебаггер не поможет, а логи — да.