Здравствуйте, IQuerist, Вы писали:

IQ>·>Потому что вызовов этого конкретного метода может быть много по всему коду, а вызововы конструктора обычно постоянны.
IQ>Но это еще хуже! Если реализация IOrderValidator, IOrderCollector и IOrderShipper существует одном экземпляре то нафига выносить их из модуля и засорять область приложения. А если их много, то необходимо явно и локально показывать их зависимость от контекста иначе логика размазывается.
Пусть одна реализация, это дело не меняет. Пишут эту реализацию другие люди, в другой команде, или это какой-нибудь RPC-интерфейс или ещё что — не важно. В вопросе главное как управлять зависимостями, а не конкретные названия классов/интерфейсов.

IQ>>>если можно где-то там, за ширмой неявно затаскивать его через конструктор в DI? Ведь достаточно будет посмотреть конструктор,
IQ>·>Зачем тебе его смотреть? Если у тебя есть ссылка на OrderProcessor — то ты смело можешь использовать любые его методы, т.к. объект уже сконструирован, компилятор гарантирует.
IQ>Компилятор гарантирует? Мне казалось DI работает исключительно в динамике.
Если кажется — крестись, или хотя бы учебники читай. Я же уже ссылку давал на вики, читал? Где там динамика?

IQ>И потом, если разные варианты поведения, то мне надо четко указать, какое использовать, если поведение одно — зачем вообще выносить его за границы модуля? Впрочем я знаю ответ... — "для unit тестов". Вот так убогие фреймворки для тестирования порождают архитектурные проблемы.
Это далеко не единственный ответ.

IQ>·>Если у тебя такой ссылки нет, то смотри wiring и найди добавь эту ссылку к себе. Если не получится — значит что-то у тебя не хвататет в зависимостях, протаскивай как надо куда надо, а не надейся на глобальные переменные.
IQ>Но мне не надо ничего протаскивать, мне надо локально указать конкретный вариант.
Какой конкретный вариант? Забудь множественные имплементации, не в них дело. Дело в том, что "конкретный вариант" тоже откуда-то должен взяться, у него можеть быть специфичный lifespan и у него могут быть свои зависимости.