T>>система при DI делится на кучу заменямых компонентов, так что сделанные изменения проще тестировать,
T>>если все прошлые изменения покрыты тестами (а когда есть DI, это сделать в разы проще), то прогонка этих же регрессионных тестов может указать на явные ошибки, когда ни тестов ни нет, то поддержка по становится чем-то вроде ходьбы по канату на высоте 100 метров без страховки
T>>применимо это к так называемым оо — системам, при фунциональщине тесты базируются на иной парадигме, там композиция делается по-другому

TG>Понял. Спасибо. Вопрос: в описываемом случае с легаси ограничитесь извлечением интерфейсов или еще и DI-контейнер используете?

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

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

если же ты начинаешь писать тесты, то тогда польза от использования IoC container сразу налицо: все архитектурные промахи (а для меня они заключаются в том, что невозможно или крайне трудно написать изолированные юнит-тесты ) сразу же явно проступают, но какое-то время на изучение того, что такое IoC container и с чем его едят, уходит, я бы тут порекомендовал почитать какую-нибудь книжку под заданный язык o DI и книжку про тестирование, чтобы было понятно, к чему надо стремиться