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

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

DI uber alies, а то что инкапсуляция идет лесом — пофигу?

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

Нда... а вы вообще программированием занимаетесь? "то ты смело можешь использовать любые его методы, т.к. объект уже сконструирован, компилятор гарантирует" компилятор по вашему конструирует объекты???

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

Имхо единственный, остальное — отмазы.

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

А вот это отличный ответ... проясняет почему разговор идет именно о сервисах. Спасибо.

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

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

DI uber alies, а то что инкапсуляция идет лесом — пофигу?

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

Нда... а вы вообще программированием занимаетесь? "то ты смело можешь использовать любые его методы, т.к. объект уже сконструирован, компилятор гарантирует" компилятор по вашему конструирует объекты???

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

Имхо единственный, остальное — отмазы.

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

А вот это отличный ответ... проясняет почему разговор идет именно о сервисах. Спасибо. Конечно остается вопрос — почему в виденом мною коде где использовался DI ничего из этого не использовалось... Это конечно не к вам претензия, а к "мейнстриму".