Здравствуйте, IQuerist, Вы писали:
IQ>>>Плодить интерфейсы
IQ>·>Так плодит интерфейсы невежество, а не DI. В каком конкретно месте DI требует интерфейсов? Я даже уверен, что большинство IoC-фреймворков вполне могут без них обходиться.
IQ>Марк Симан невежество, не я сказал...
"Требовать" и "предлагать" — несколько разные вещи. Да, какие-то аспекты архитектуры требуют интерфейсов, но это не DI.
IQ>>>Любая, самая идеальная вещь может быть плохой там, где она лишняя.
IQ>·>Так отказывайся от ambient context. Он лишний же.
IQ>Он собственно появился по одной простой причине — сугубо синтаксическая группировка всех часто используемых сервисов. Его можно смело выкинуть и создавать все нужные сервисы с помощью new.
Хорошо, но уже лучше. Правильно, можно выкинуть. Осталось выделить все эти new в отдельный код, называемый composition root и получится DI здорового человека.
IQ>>>
Вы думаете local context такой стойкий потому что разработчики ленивые? local context такой стойкий потому, что в него отлично ложатся контексты бизнес операций.
IQ>·>Нет, просто невежественные, перечитай топик — много народу тут отметилось которые вообще не знают что такое CI. Вот посмотри на код даже хорошего трудолюбивого студента — код плохой потому что у студента мало опыта и знаний, а не потому что код так лёг.
IQ>Имхо если мало знаний нефиг принимать серьезные решения.
Хм... Как мило.
Т.е. применить ambient context это несерьёзное решение:
Правильная реализация Ambient Context может оказаться непростой задачей.
а вот constructor injection это серьёзное решение:
... если есть сомнения, выберите внедрение в конструктор: вы никогда сильно не ошибетесь в этом выборе. ... Его легче понять и проще надежно реализовать, чем любой из других DI паттернов. Вы можете построить целые приложения только с одним внедрением в конструктор
IQ>>>Я не хвастаюсь. Просто раньше из этих хелперов состояли DI сервисы.
IQ>·>Так куда эта паутина зависимостей делась? Замели под коврик?
IQ>Эта паутина, в данном конкретном случае, никогда никого не интересовала (и до сих пор не интересует). Как например и clr code проекта или как sql сервер парсит запросы и т.д. В этом мире прорва вещей детали которых здесь и сейчас абсолютно не важны.
Правильно, зачем думать — прыгать надо.
IQ>·>Вот же: http://rsdn.org/forum/design/6560633.flat#6560633Автор: ·
Дата: 22.09.16
IQ>·>Более разжёвано почитай в том талмуде, который ты показывал, но, похоже, не ещё читал. Задавай вопросы, если что-то непонятно.
IQ>·>Спасибо, что ты наконец-то решил почитать что тут пишут.
IQ>
Ну вы уж совсем меня за хейтера держите. О DI читал очень давно и сперва мне показалось, что из за ада с интерфейсами никто его использовать не будет. И так я думал до тех пор, пока меня не подключили к загибавшемуся проекту где бедолага программер просто утонул в зависимостях которые сам наплодил и конечно же он понятия не имел нафига они ему нужны в ядре бизнес логики, которое нужно исключительно для 1 проекта.
Что ты читал? И где там написано, что интерфейсы обязательны?
IQ>>>Я глянул ваши ответы и не смог найти механизм, который будет в вашем случае создавать и хранить сервисы и инжектить их в клиенты.
IQ>·>Зачем хранить сервисы? Сразу создавай и связывай что как надо в composition root. Инжектятся они с помощью CI, десятый раз говорю.
IQ>Хотя бы раз назовите фреймворк, который используете.
Никакой, plain java.
IQ>В composition root регистрируются сервисы с клиентами кто их связывает?
В composition root никто не регистрируется, какие ещё сервисы-клиенты? Твой вопрос не имеет смысла, т.к.
A Composition Root is a (preferably) unique location in an application where modules are composed together.
Пример по ссылке выше, в конце сообщения.
IQ>Что такое CI (constructor injection)?
Передача зависимостей в конструктор объекта. Пример там же. Ну и в твоём талмуде.
IQ>Кто/что вам его предоставляет?
Java Language Specification.
