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

IQ>>Нда... Как говорит народная мудрость лучше всего бандиты решают те проблемы которые сами и создают В посте Seemann создал инвалидное решение, огреб проблем и доблестно все порешал с помощью constructor injection! Какую же проблему он решил? А оказывается OrderProcessor.Process(Order order) внутри использует IOrderValidator!
·>Не только IOrderValidator, но и IOrderCollector, а потом со временем добавление IOrderShipper.

IQ>>Но зачем явно передавать его в конкретный метод,
·>Потому что вызовов этого конкретного метода может быть много по всему коду, а вызововы конструктора обычно постоянны.

Но это еще хуже! Если IOrderValidator, IOrderCollector и IOrderShipper в одном экземпляре то нафига выносить их из модуля и засорять область приложения. А если их много, то необходимо явно и локально показывать их зависимость от контекста иначе логика размазывается.

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

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

·>Если у тебя такой ссылки нет, то смотри wiring и найди добавь эту ссылку к себе. Если не получится — значит что-то у тебя не хвататет в зависимостях, протаскивай как надо куда надо, а не надейся на глобальные переменные.

Но мне не надо ничего протаскивать, мне надо локально указать конкретный вариант.

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

IQ>>Нда... Как говорит народная мудрость лучше всего бандиты решают те проблемы которые сами и создают В посте Seemann создал инвалидное решение, огреб проблем и доблестно все порешал с помощью constructor injection! Какую же проблему он решил? А оказывается OrderProcessor.Process(Order order) внутри использует IOrderValidator!
·>Не только IOrderValidator, но и IOrderCollector, а потом со временем добавление IOrderShipper.

IQ>>Но зачем явно передавать его в конкретный метод,
·>Потому что вызовов этого конкретного метода может быть много по всему коду, а вызововы конструктора обычно постоянны.

Но это еще хуже! Если реализация IOrderValidator, IOrderCollector и IOrderShipper существует одном экземпляре то нафига выносить их из модуля и засорять область приложения. А если их много, то необходимо явно и локально показывать их зависимость от контекста иначе логика размазывается.

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

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

·>Если у тебя такой ссылки нет, то смотри wiring и найди добавь эту ссылку к себе. Если не получится — значит что-то у тебя не хвататет в зависимостях, протаскивай как надо куда надо, а не надейся на глобальные переменные.

Но мне не надо ничего протаскивать, мне надо локально указать конкретный вариант.